Work bd issue <ISSUE_ID>. The grind harness has ALREADY selected and claimed this issue for you — its status is `in_progress`. Do NOT run `bd ready`, do NOT pick a different issue, and do NOT invent, guess, or re-derive any issue id. Operate ONLY on the id <ISSUE_ID>, exactly as written above; the only bd issue id that should appear in any of your bd commands is <ISSUE_ID>.

You ARE the worker for this issue. Do NOT invoke `ortus grind`, `goal.sh`, `ralph.sh`, or any other queue orchestrator from inside this session.

The issue you are working (already claimed for you):

<ISSUE_DETAILS>

Procedure:
(1) Complete the work the description and acceptance criteria require. Run the tests and gates the acceptance criteria call for; verify they pass.
(2) Commit the completed work on the issue branch grind handed you (`ortus/<ISSUE_ID>`), with a real commit message you write yourself: an imperative subject of at most 72 characters counted over the whole line including the `<ISSUE_ID>: ` prefix — describe the change, do not restate the issue title, no trailing period, no `...` — then a body of at least two paragraphs of plain-text prose, under 8,000 characters in all, naming in backticks at least one function, class, or file that actually appears in your diff and none that does not (a diff with no nameable symbol still names one of its files), never an inventory of the files touched, and never narration of how the commit was produced (attempt counts, verifier verdicts, phase names, candidate hashes). Only an over-long subject is repaired in place; a message that breaks any other rule is replaced by a weaker deterministic assembly before it merges. Commit ONLY on that branch, and leave anything you deliberately did not finish uncommitted. Do NOT run `bd close`, `git push`, `git stash`, `git reset`, or `git worktree add`, and do NOT create or switch git branches or touch the integration branch (normally `main`) — the outer Ortus process alone merges, closes, and pushes. If you need a throwaway copy of a tree, build it with `git archive <ref> | tar -x -C "$TMPDIR/tree"` (pathspecs narrow it to the paths you need; always extract outside the repository — extracting into the repo root overwrites your uncommitted work with the archived content) when comparing file content, or with `git clone --shared` when the copy must build or needs git metadata — a shared clone is a plain directory that ordinary removal deletes, not a worktree. `git worktree add` is forbidden because the sandbox's read-only bind mounts make the registration unremovable. The machine verification pipeline judges your exact committed range next — it clones the branch and re-runs every criterion check, so finished work you leave uncommitted fails verification as unjudgeable.

(3) Add the completion comment with `bd comments add <ISSUE_ID> "..."` carrying the `**Changes**` block, the one-line `**Verification**` summary, and the `**Claims v1**` block — one `AC-N: pass` or `AC-N: fail` line for every criterion in the work spec's Observable criteria, each stating the result of the criterion check you actually ran. The machine pipeline re-runs every check and diffs your claims against its measured results: a claim that disagrees with the measurement fails the round in either direction, and a comment with no `**Claims v1**` block fails the same way. Run the checks, report what you saw.

The work spec is frozen for the life of your claim: NEVER edit the claimed issue's packet — no `bd update <ISSUE_ID> --acceptance/--design/--description/--title/--notes`. Verification judges the claim-time criteria by hash, so any packet edit fails the whole round no matter how right the edit is. If the spec itself is defective — a criterion check that cannot be run as written, a contradiction, a wrong command — that is report-and-stop: say exactly what is wrong in a durable comment (`bd comments add <ISSUE_ID> "..."`), run `bd human <ISSUE_ID>`, and exit; the operator or planner repairs the spec before the next claim.

You are done when the work is complete and committed on the issue branch and the completion comment is posted. You are NOT driving the queue to zero; the outer Ortus process handles queue exhaustion, retries, verification, and orphan-claim recovery from observable bd state. Your scope is this one issue: <ISSUE_ID>.

When the procedure is complete, end the session. Do not pick a second issue. Do not add a final verification comment — the verifier writes it. Do not output a sentinel; the evaluator reads this transcript.

If repository reality contradicts the work spec, or a material architecture/product choice is still unresolved, this is a structured planning gap. Do not improvise. Preserve whatever exists — commits already on the issue branch stay there, and edits you have not committed stay uncommitted; discard and close nothing. Add one durable comment with `bd comments add <ISSUE_ID> "PLAN-GAP: <the contradiction or missing decision, evidence, and affected files/symbols>"`, then run `bd human <ISSUE_ID>` to route the issue to planning/human handling and exit. Do not add the final verification comment. The harness will apply its configured recovery policy to the claim.

For any other human-only blocker, run `bd human <ISSUE_ID>` and exit without closing.
