Generated from cat-harness/processes/process/crdm-signoff.bpmn by gen-processes-viz.ts — do not edit here. All processes

CRDM Phase 5 — beans and sign-off

Process_CRDM_Signoff · strict · 7 step(s)

The approved requirements become work-plan items, the BA signs off, and the branch is announced on the issue. The announcement is on the single edge into delivery, so the three loops back into implementation do not re-announce.

BPMN diagram: CRDM Phase 5 — beans and sign-off

How it connects

Lanes — who acts

lane role what it does here
BA / Feature Requestor business-analyst Makes two decisions of different character here: BA_Signoff approves what was drafted, and BA_ChooseKg commits it — or explicitly does not — to a knowledge-graph destination, where NONE is a legitimate answer rather than a refusal to answer. Only this lane may decide that a requirement is fully carried by the code and becomes a commit and nothing else; an agent that decided so on its own would be placing a node in somebody else’s graph.
Agent authoring-agent Turns Lane_BA’s two decisions into durable artefacts: A_CreateBeans and A_RecordKg each mint their own bean directly with the CLI, since the engine’s own vocabulary has no create, only claim, note and resolve on an instance’s bean. A_AnnounceBranch then closes the phase on its one path to End with no loop of its own, so it fires exactly once — Phase 6’s own loops re-enter implementation on the same branch without ever crossing back through this edge.

Steps

Every one of the 7 step(s) is documented.

step lane skill / sub-process what it does
Phase 5: Create beans
A_CreateBeans		 Agent todo-manager The agent mints the implementation beans itself with
beans create, running the exact-title existence check first. The engine has
no create op — it claims, notes and resolves the instance’s OWN bean — so
what this step records here is a note that the plan now exists.
Sign off on requirements
BA_Signoff		 BA / Feature Requestor calls Adjudication
adjudication		 The business analyst / requester signs off on the agreed requirement set, on the issue: what was agreed and what was deferred. Recorded as their decision, with its reason, never by an agent on their behalf. Since issue #2405 (FR-013) it IS an adjudication: it calls Process_Adjudication with the requirement-set answers, and every answer goes through A_RecordSignoff before anything follows it.
Record the sign-off as a requirement-signoff attestation
A_RecordSignoff		 Agent adjudication THE RECORD, and not relaxable: a judgement nobody wrote down is indistinguishable from one never made (adjudication, A_RecordEntry). Append one requirement-signoff record to test/attestations/requirement-signoff/<set slug>.attestations.json — who (kind, id, actor), at, scope (the set or one member), the outcome from the requirement-set code list, the stage it moves the set to, the reason, and the permalink to the issue comment where it was decided — and set the set’s stage to match. Issue #2405 FR-011 / FR-012.
GW_SignoffRecorded after this reads the record back, so this step cannot be skipped by completing it: a sign-off that left no attestation loops here again.
Announce the branch on the issue
A_AnnounceBranch		 Agent crdm-requirements-workflow
coordinate		 On CREATING the feature branch, comment on the issue:
the branch name, the process and phase, and the beans claimed. Visibility is
the whole point — without it a sibling session or a human cannot tell that work
has begun, only that it has finished.
Deliberately on this edge and not inside Phase 6. The three loops back into
A_Implement (increment rejected, MVP not ready, feedback translated) re-enter
implementation on the SAME branch, and re-announcing on each would be noise.
Announce once, when the branch is created.
Before announcing, run the collision review that starts any new unit of work
(coordinate, “Starting new work”): open PRs and in-progress beans checked
against the branch’s files and subject, scaled to the blast radius, and the
result recorded in the bean before the first edit.
Offer the knowledge-graph destinations for the agreed set
A_OfferKg		 Agent kg-contribution-offer THE STEP THAT WAS MISSING. Requirements were elicited, agreed and signed off, and then existed as an issue and a conversation — so the output of the process that exists to produce durable requirements was the one thing the knowledge graph never learned.
ONE question for the SET, not one per requirement: a six-phase run can agree many, and asking six times is the same failure as a form that re-asks what it was already told.
The options are DERIVED from the graphs this instance declares in <name>.json, read at the time of asking, so an instance that adds a graph gets it in the offer without anybody editing a skill. Never a list typed from memory.
Choose a destination, or none
BA_ChooseKg		 BA / Feature Requestor kg-contribution-offer A PERSON’S STEP, and none is one of the answers rather than a refusal to answer. A requirement whose whole content is carried by the code becomes a commit and nothing else; a graph that acquires a node for it is a graph with a node nobody will ever read.
The default creates NOTHING. An agent that decides on its own that a requirement “is really a skill” has manufactured a node nobody asked for, in a graph somebody else maintains — which is what this step exists to prevent.
Run placement, and raise a bean for the authoring
A_RecordKg		 Agent placement The offer produces a DECISION, not a node. placement then decides instance, graph and node kind — it is the step that catches a hardcoded path or a literal naming one folio — and the authoring itself becomes a bean, because work here is a bean before it is a file.
op="note" and not create, for the reason A_CreateBeans above states: the engine has no create op — it claims, notes and resolves the instance’s OWN bean. The agent mints the authoring bean itself with beans create, running the exact-title existence check first, and what this step records is a note that the decision was taken.

Decisions

Every one of the 2 decision(s) is documented.

decision what decides it branches
Sign-off on the record?
GW_SignoffRecorded		 Computed, never chosen: decisions/requirement-signoff-recorded.dmn reads signoffRecorded and signoffOutcome, which check:requirements prints from the set’s recorded sign-offs (its signoff-facts flag). missing loops back to the record; proceed is an approval (as written or amended); stop is a recorded reject, defer or cancel. proceed → Offer the knowledge-graph destinations for the agreed set
stop → Not approved — recorded, with its reason
missing → Record the sign-off as a requirement-signoff attestation
A destination?
GW_KgChosen		 Drawn as a branch rather than folded into the task above, because none being a real outcome is the property worth being able to see. A diagram where every path ends in a created node is a diagram of a ritual. a graph → Run placement, and raise a bean for the authoring
none — recorded as an answer → Announce the branch on the issue