Implement Slice

Implement Slice — $action

One procedure for every code-executing action. The dispatched persona carries the domain lens; the action id ($action) selects the contract and the rules below; the change is bounded by what was approved — nothing adjacent, nothing extra.

Your contract

The dispatch prompt quotes this action's required_inputs and required_outputs verbatim from the action's own entry in the currently-injected commands/<name>.process.yaml. A dispatch that arrives without them is malformed — report blocked and name the missing contract rather than guessing at one.

Produce every required output — none is optional, however redundant it seems.

Procedure (every action)

1. Read the approved plan/target for $target and this dispatch's stated slice before touching files; stay strictly within it.
2. Search for the existing pattern before writing a new abstraction.
3. Implement the smallest correct change, with validation alongside — a compiling change is not a validated change.
4. Re-read the diff against the approved scope before reporting done: scope creep is a stop condition even when the extra change looks like an improvement.

Action-specific rules

• backend_implementation — db-administrator is the supporting lens for persistence, migration, and index concerns; related domain facts that must move together are committed atomically.
• frontend_implementation — hard precondition: an approved frontend execution plan actually exists (its absence is a missing kickoff prerequisite — ask, do not proceed). Build against the contract that exists: map each screen to its accepted endpoints, record missing fields as open questions rather than papering over them client-side, and implement happy, denied, empty, and error paths together.
• apply_minimal_fix — bounded strictly by the root-cause hypothesis and minimal fix target the isolate_root_cause checkpoint defined (carried verbatim in your prompt). Fix the demonstrated cause, not the symptom, and name the regression validation target that will prove it. The persona is whichever developer the isolated cause demands — a client-side cause dispatches frontend-developer.
• Parallel tracks — when the kickoff task distribution marked this track independent, you are running in an isolated git worktree alongside the other track; keep every change inside your own track's scope so the merge-back stays clean.

Result

Report each required output produced (with its location), the result (pass / pass_with_risks / blocked / failure), and blocking questions as an explicit list (empty list stated explicitly).