Freeze the interface first, implement against it, instead of discovering it mid-build

You are defining the contract for this feature before writing any implementation against it — every function signature, request and response shape, and error case this feature introduces must be fully specified and approved before implementation starts, not discovered incrementally as the build proceeds.

FEATURE
A new bulk-tag-update endpoint for the prompt library admin panel, letting an editor apply a tag to many prompt entries at once.

WHAT SPECIFICALLY NEEDS A FROZEN SHAPE
The POST /api/admin/prompts/bulk-tag request body shape, the response shape including per-item success or failure, and every distinct error case such as an invalid slug or a tag exceeding the allowed length.

WHO ALREADY CONSUMES OR WILL CONSUME THIS CONTRACT
The admin panel frontend, currently being built in parallel by a different session against this exact contract.

VERSIONING STRATEGY IF THIS CONTRACT NEEDS TO CHANGE LATER
This is an internal admin-only endpoint with one consumer, so an in-place change is acceptable as long as both sides update together; it is not a public API needing deprecation.

STAGE ONE — CONTRACT DEFINITION ONLY
Write out every element of The POST /api/admin/prompts/bulk-tag request body shape, the response shape including per-item success or failure, and every distinct error case such as an invalid slug or a tag exceeding the allowed length. in full: exact function signatures with parameter and return types, exact request and response shapes if this crosses a network or process boundary, and every distinct error case with what triggers it and what the caller receives back for it. Do not write any implementation logic in this stage — a type signature and a stub that throws not-implemented is acceptable here; real logic behind it is not.

Do not proceed past this stage until the contract is explicitly approved. State clearly that you are waiting for that approval.

STAGE TWO — IMPLEMENTATION AGAINST THE FROZEN CONTRACT
Once approved, implement strictly against the contract from stage one. If, while implementing, a genuine need to change the contract emerges — a case that turns out to need a different shape, a return type that cannot actually express what the implementation needs to convey — stop implementing, name exactly what needs to change and why, and treat this as a new stage-one proposal requiring its own approval, not a change to quietly make and mention afterward.

CHECK AGAINST CONSUMERS
Before any contract change is approved, whether at the start or mid-implementation, check The admin panel frontend, currently being built in parallel by a different session against this exact contract. explicitly — a contract change that looks purely additive to the feature being built can still be a breaking change for an existing consumer that pattern-matches on the previous shape, and that has to be confirmed against the actual consumer code, not assumed safe because the change felt small from inside this feature's own perspective.

CONSTRAINTS
- If This is an internal admin-only endpoint with one consumer, so an in-place change is acceptable as long as both sides update together; it is not a public API needing deprecation. indicates this contract is public or crosses a boundary this codebase does not fully control, such as an external API consumer, treat a contract change as requiring a deprecation path, not an in-place edit, and say so explicitly.
- Do not let implementation details leak backward into the contract definition — the contract describes what callers can rely on, not how the feature happens to be built internally, and conflating the two makes the contract brittle to implementation changes that should never have affected it.

OUTPUT
Stage one's full contract, an explicit wait-for-approval line, and only then, once approved, stage two's implementation strictly matching it.