Documentation

The spec drawer

The spec drawer is where you read and act on a single spec, the contract between intent and the tickets that implement it. Open it from Work or Complete (a spec row, or a ticket that belongs to that spec).

Reading sections

The compact navigation row opens Overview, Acceptance, Tickets, and Evidence. Overview shows the source, a bounded Completion screenshots strip when any exist, and the full spec document.

Overview places the screenshot strip after status, source, and PR metadata, and before the Details document. Two thumbnails on desktop, one on a narrow drawer, the unique count, and one View all screenshots action that opens the full-size viewer. Each thumbnail shows the whole picture in its own shape. Nothing is cropped or stretched. A screenshot must be at least 1440×900 and sharp. Hub refuses a smaller or blurry one when it is uploaded. Capture the screen itself at 2x scale, not a thumbnail or a small picture made larger. The spec body is not replaced or truncated. No screenshots means the strip is omitted, not an empty placeholder.
Acceptance counts all criteria. The number is not a completion score or a human verdict; read the checklist for each criterion's state.
Tickets counts current members, including open and done. Eight rows show initially; search, status filters and Show all keep every member reachable. Choose Archived explicitly to inspect archived members.
Edit order reveals Up/Down for Recommended order (hint). The hint never blocks Start; hard dependencies still apply.
Evidence shows totals and provenance plus every eligible structured screenshot (including supported older agent-provided proposals) as openable pictures in a gallery. There is no extra Accept control on those pictures. Passing runs and long notes start folded; failing runs stay open. Expand to read original test details and links. Human Accept is additional confidence, not a deploy gate.

Acting on a spec

drafting → Approve or Archive…
approved → Reopen, Complete, or Archive…
archived → Restore

Claim/Unclaim, Assignee and Copy Prompt share the visible toolbar with the main lifecycle action. Actions holds Reopen, Archive, governed follow-up and Record decision. Existing availability, lifecycle rules and confirmations still apply. Narrow drawers provide a labelled overflow arrow while keeping Actions reachable.

This Spec is still drafting. Approving lets it finish. Its criteria lock once it's finished or its evidence is accepted.

Out of date

When open tickets no longer match this spec, a card under Status (above Related) shows one control. The toolbar does not repeat it.

A saved plan shows Out of date counts, keep as-is / update / specs to create, Prepared by when an agent saved it, and Review changes. It opens that plan. It does not build a new one.
Open tickets that are out of date with no saved plan show Review changes. It opens this spec's review.
A finished, replaced, or withdrawn plan is not live. If nothing is out of date, the card is omitted.

Apply stays on the Review changes drawer. This drawer does not apply the plan.

Switching a spec on

A switched-on spec checks each ticket against the requirement it covers. A ticket is then out of date only when a requirement it covers changes.

Where the switch is. Open the spec, choose Acceptance, and look under Requirements. The button says what a click does: Switch on requirement checks or Switch off requirement checks. The line above it says what the spec does now: Checking each requirement or Not checking each requirement. A spec with no requirement setup has no switch yet. Use Preview requirement setup first. A spec that is On hold has no switch either. Choose Review changes there and review the hold first.
Who can switch on. Only a signed-in person. An agent that tries gets "Only a person can switch a spec on." and nothing changes.
Hub checks first. Hub switches on only when the spec is ready, for example when every open ticket is linked to a requirement. If something is in the way, the spec stays as it was and Requirements lists what to resolve.
Who can switch off. Anyone, a person or an agent. If a requirement change was saved while the spec was on, the checks stay on and Hub says so. Otherwise Hub checks tickets against the whole spec again and keeps the requirement names.

Adding and rewording criteria

On Acceptance, Reword… under a criterion opens its wording in place, and Add criterion… after the last one opens an empty field. On a spec that checks each requirement, that button reads Add requirement…. Empty text cannot be saved. You never see or type a requirement's id: a reworded criterion keeps the one it had, and Hub gives a new criterion its own.

On a spec that checks each requirement, a new criterion gets a card in Review changes (see New requirements below). A new wording that changes what is asked for holds the open tickets linked to that criterion until someone settles them in Review changes.
On a spec that does not, Hub checks tickets against the whole spec, so a change can mark its tickets Out of date. That is true for a change saved by a person and for one saved by an agent.
A criterion is saved as one line. Hub removes line breaks, comment markers and code fences, and cuts text after 2000 characters. A criterion that looks like it holds a password or an API key is not saved. A criterion you did not change is left as it is.
Ticking a box never marks a ticket Out of date.
Rewording clears that criterion's box. The tick was for the earlier wording.
A person's change is recorded as approved by that person. An agent's change to a spec that checks each requirement stays a proposal until a person approves it.
If the spec changed in another tab, or someone else changed it, nothing is saved. The drawer says so, keeps your text, and offers Reload.
A finished spec, or one with completion evidence, cannot take a criteria change here: no new wording, no added or removed criterion. Start a follow-on spec for the change.

New requirements

When someone adds a requirement to a switched-on spec and no ticket covers it yet, Review changes shows a card for it with a drafted ticket title and text. Read the draft as Readable or as Line diff, the same two views a ticket update has. Choose what should happen:

Create ticket makes a ticket from the draft and links it to that requirement. The new ticket gets the spec's assignee.
Not planned keeps the requirement on the spec and records that no ticket is planned for it.
Later keeps the requirement on the spec and records that a ticket will come later.

Until someone decides, Acceptance shows No ticket yet next to that requirement.

Each requirement in Acceptance shows one coverage chip:

Planned: a ticket covers the whole requirement as it reads now, or tickets between them cover every required part. Planned is not delivered; delivery is checked from evidence.
Partly planned: some work is linked, but not for the whole requirement. When the requirement has reviewed required parts, a line under it says how many have a ticket, for example "1 of 2 required parts has a ticket."
Assigned: a ticket is linked, but to an earlier wording ("Linked to an earlier wording."), or the link is not confirmed yet.
No ticket yet: nothing is linked and no one has decided. A line under it reads "It stays here until someone adds a ticket or rewords it."
Not planned and Later: a person decided, with a reason.

On a spec with requirement checks switched off, the same chip sits after the criterion's text in the Acceptance checklist, and its lines sit under it. A spec with checks off is checked as a whole, so its rows show no Rule chips.

Not planned and Later each need a reason, up to 2,000 characters. Apply stays off until every one of them has a reason. The reason then shows under that requirement in Acceptance; a long reason folds to two lines, with More and Less to open and close it. A requirement marked Not planned or Later is still not planned with a ticket; it stays visible so no one loses track of it.

If a requirement changes after its ticket shipped, the card drafts linked follow-up work and shows the earlier and new wording. Create ticket makes new work for the new wording and links it to the shipped ticket. The shipped ticket and its evidence stay as they are.

For a small rewording whose meaning needs a person's judgment, this card also offers Still covered. It needs a reason, up to 2,000 characters. Apply saves that judgment on the spec for this change; it does not change the shipped ticket or transfer its evidence to the new wording. A later change needs a new review. A material change requires new work and does not offer Still covered.

Create ticket on a completed spec needs a person to reopen the spec first, or start a new spec for the change. A refusal gives Open the spec and keeps Create Apply off until recovery. Not planned, Later and Still covered remain available when offered.

Changing a completed spec's criteria, including approving a pending revision, needs a successor spec or a governing Decision accepted by a person.

When an Apply includes any of these new-requirement choices, everything in that Apply saves together. If any part cannot save, for example because the spec changed in another tab, nothing is saved: Review changes shows that the review changed, and you choose Reload, check your choices, and apply again. Choosing Create ticket twice never makes a second ticket. If a ticket already covers the requirement, Hub uses that ticket instead and says "This ticket was already created." (or "These tickets were already created.").

After Apply, Review changes says what was saved, for example "The ticket was created. 1 requirement was marked Later." The message shows beside Apply, so you see it wherever you were in the list.

Partly applied

When Review changes updates several tickets and one does not save, the spec shows Partly applied under Acceptance. It names each ticket that did not update, by title, with a plain reason. Retry runs only those tickets again; Review changes reopens the review. Only a person can Retry. A ticket that already updated is never written twice, and if nothing is left, Retry says so. If Hub stopped mid-save, it finishes the stopped tickets on its next start.

Archive… asks what happens to the tickets: archive them all, keep them on the Goal, move them to another spec, or leave them where they are.