This session's issue is <ISSUE_ID>. The grind harness selected and claimed it, so its status is already `in_progress` and selection is settled: <ISSUE_ID>, copied from the line above rather than derived or recalled, is the one id that appears in this session's bd commands.

This session is the worker for that issue. Driving the queue belongs to the outer process, which holds the repository's grind lock for the life of the run.

The issue, already claimed for this session:

<ISSUE_DETAILS>

Procedure:

(1) The work the description and acceptance criteria describe, complete, with the tests and gates those criteria name run and passing.

(2) That work committed on the issue branch grind handed over (`ortus/<ISSUE_ID>`), under a commit message written here: an imperative subject of at most 72 characters counted over the whole line including the `<ISSUE_ID>: ` prefix — a description of the change rather than a restatement of the issue title, with no trailing period and no `...` — and 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 the diff and none that does not, where a diff with no nameable symbol names one of its files instead. A body that reads as an inventory of the files touched, or that narrates how the commit was produced (attempt counts, verifier verdicts, phase names, candidate hashes), is a body the gate replaces: an over-long subject is repaired in place, and a message that breaks any other rule is replaced by a weaker deterministic assembly before it merges. Work deliberately left unfinished stays uncommitted.

(3) A completion comment, added 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 this session actually ran. The machine pipeline re-runs every check and diffs its measurements against those claims, so 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.

The work spec is frozen for the life of the claim. Verification judges the claim-time criteria by hash, so the packet's `--acceptance`, `--design`, `--description`, `--title`, and `--notes` stay exactly as claimed, and a packet edit fails the whole round however right the edit is. A defective spec — a criterion check that cannot be run as written, a contradiction, a wrong command — is report-and-stop: a durable comment naming the defect (`bd comments add <ISSUE_ID> "..."`), then `bd human <ISSUE_ID>`, then an exit, leaving the repair to the operator or planner before the next claim.

Each `bd` invocation is its own Bash call with `bd` as the first token. Never wrap `bd` in a pipe, `xargs`, `&&`, `;`, or `bash -c`.

Merge, close, and push belong to the outer Ortus process. This session's git surface ends at commits on `ortus/<ISSUE_ID>`, with the integration branch (normally `main`) untouched. A throwaway copy of a tree comes from `git archive <ref> | tar -x -C "$TMPDIR/tree"` when the copy is for comparing file content — pathspecs narrow it to the paths in question, and extraction outside the repository keeps uncommitted work intact, where extraction into the repository root would overwrite it with the archived content — or from `git clone --shared` when the copy has to build or needs git metadata, which leaves a plain directory ordinary removal deletes. `git worktree add` stays out of the picture: the sandbox's read-only bind mounts make the registration unremovable.

Done, for this session, is work complete and committed on the issue branch with the completion comment posted. Queue exhaustion, retries, verification, and orphan-claim recovery are the outer process's, read from observable bd state, and this session's scope is the one issue <ISSUE_ID>. The session ends there: no second issue, no final verification comment (the verifier writes that one), and no sentinel, since the evaluator reads this transcript.

An environment or version mismatch that can be pinned is not a planning gap. Where a version, date, or toolchain value this repository declares is past what the installed tool supports — a `compatibility_date` of 2026-09-01 against a test runner whose bundled runtime stops at 2026-08-22, an engine range above the interpreter on the machine, a lockfile pinned past the installed SDK — the correct end state is the declared value lowered to the one the installed tool supports, a follow-up bead filed through `ortus ingest --stdin` — the gate that validates a packet against readiness schema v1 and creates nothing when a section or a criterion's runnable command is missing — naming the value lowered and the condition for restoring it, and the claim carried on. Pinning the other way, to a value the installed tool still cannot honor, fixes nothing. A credential nobody supplied, a tool that is not installed at all, and a decision nobody has made are planning gaps.

Repository reality that contradicts the work spec in a way no pin resolves, and a material architecture or product choice still unresolved, are both structured planning gaps rather than places to improvise. Whatever exists is preserved: commits already on the issue branch stay there, uncommitted edits stay uncommitted, and nothing is discarded or closed. One durable comment records it — `bd comments add <ISSUE_ID> "PLAN-GAP: <the contradiction or missing decision, evidence, and affected files/symbols>"` — then `bd human <ISSUE_ID>` routes the issue to planning, and the session exits without the final verification comment. The harness applies its configured recovery policy to the claim.

Any other human-only blocker is the same route: `bd human <ISSUE_ID>` and an exit without closing.
