mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 15:16:56 +01:00
9e5273443f
Implements every confirmed finding from the workflow-based audit of CURABIS Standard's agent model (7 finders + adversarial verification, 8 confirmed / 5 refuted): 1. Roemer/Florence phantom wiring - roemer.agent.md claimed Florence's heartbeat "may summon me when a ward smells of drift" with nothing in florence.agent.md or HEARTBEAT.md implementing it. Fixed by adding an explicit "Kald Roemer" instruction to HEARTBEAT.md ward 6 (agent visibility, his actual domain), mirroring ward 8's existing "Kald Weber" pattern, and correcting roemer.agent.md's own claim to match. 2. m365.agent.md's "Florence's morning brief pattern" was a one-way orphaned reference - a full 4-step pattern with nothing in florence.agent.md implementing it. Added it to florence.agent.md as an explicit on-demand capability, separate from the timestamp-gated Round protocol. 3. An Ergasterion "PROCEED WITH CHANGES" ruling had no way to be checked against the eventual diff - al-review's checklists never referenced it. Added ERGASTERION_RULING to the [CURABIS-STATE] vocabulary, wired Ergasterion to write it, and added a BLOCKing checklist item to al-review's Titus checklist that verifies required changes were actually implemented. 4. curabis-task-state-check.yml was headered "Deterministic enforcement (not LLM diligence)" but only checks checkbox order, only blocks anything if a human separately enabled branch protection (never verified anywhere), and doesn't exist at all for the PTE track. Corrected the header's claims and added Roemer station 14 to verify branch protection is actually configured. 5. Mode C's only safeguard against a support user reaching Curabis/QualityHub was a single manual eyeball check with no re-check ever. Strengthened Step 2 to cover team-inherited and org-default access paths, added an append-only support-user registry, and added Roemer station 15 to periodically re-verify every registered user against it. 6. Columbo's persona was presented as genuine autobiography with no disclosure of its fictional TV origin (Levinson & Link, Peter Falk), unlike Smiley which discloses explicitly. Added a reader-facing editorial note - never something Columbo says aloud, since unlike Smiley he actually performs the persona to customers.
126 lines
6 KiB
Markdown
126 lines
6 KiB
Markdown
---
|
||
bc-version: [all]
|
||
domain: architecture
|
||
keywords: [task-state, persistence, resumability, bc-task, pull-request, pte, appsource, lifecycle, operator-handoff]
|
||
technologies: [al, mcp]
|
||
countries: [w1]
|
||
application-area: [all]
|
||
---
|
||
|
||
# Task State Lives in the Mandatory Artifact — Never a New Store
|
||
|
||
## Description
|
||
|
||
A task's progress through the lifecycle gates (start, red, green, review,
|
||
merge) must be readable by both the operator and Claude, must survive a
|
||
machine change, and must survive an **operator change** — a different
|
||
developer picking up where the last one stopped. That rules out anything
|
||
machine-local (a gitignored file, session memory).
|
||
|
||
The correct home is not a new, bespoke state store — it's whichever
|
||
artifact is **already mandatory** for that task's flow:
|
||
|
||
- **PTE** (`app.json` idRange 50000–99999): a BC sub-task always exists
|
||
before development starts (`[[development-requires-bc-task]]`, no
|
||
exceptions). The sub-task's comments (`taskComments`, PAG6102902) ARE the
|
||
state store. Nothing new to build — just a disciplined format for what
|
||
gets written there.
|
||
- **AppSource**: no BC task is mandatory today (`[[one-task-in-progress-at-a-time]]`
|
||
— "AppSource app: offer, never block"). The mandatory artifact instead is
|
||
the pull request. Open it as a draft early — at the start gate, not only
|
||
when work is ready for review — and its description carries the state as
|
||
a checklist.
|
||
|
||
Do not build a third mechanism (a community example: a dedicated
|
||
`workflowSessionManager` with its own session IDs) when a task already has
|
||
a mandatory home. Building a parallel store means two sources of truth that
|
||
can drift; the artifact the flow already requires cannot drift from itself.
|
||
|
||
## State vocabulary (both flows use the same stages)
|
||
|
||
```
|
||
TASK_STARTED branch created, BC gitHubDevStatus = In Progress (PTE only)
|
||
ERGASTERION_RULING: PROCEED | PROCEED_WITH_CHANGES | RECONSIDER (HIGH tier only,
|
||
before implementation — see below)
|
||
RED_CONFIRMED test written, developer confirmed the failing run
|
||
GREEN_CONFIRMED test passes, developer/CI has actually run it
|
||
REVIEW: APPROVE | APPROVE_WITH_NOTES | BLOCK al-review's verdict
|
||
ON_HOLD parked mid-task (Focus gate) — always includes why
|
||
MERGED track branch merged, BC Done (PTE) / PR merged (AppSource)
|
||
```
|
||
|
||
**2026-08-03 — `ERGASTERION_RULING` carries required changes forward.** When
|
||
a HIGH-tier task convenes the Ergasterion (`ergasterion.agent.md`) before
|
||
implementation, its ruling — and, critically, the *exact required changes*
|
||
for a PROCEED_WITH_CHANGES or RECONSIDER disposition — is written into the
|
||
same trail, not just decided in the moment and forgotten. Without this,
|
||
nothing downstream (al-review, at merge time) has any way to check whether
|
||
the implementation actually honored a design ruling that happened before
|
||
code existed. The checkpoint text includes the required-changes list
|
||
verbatim, e.g.:
|
||
|
||
[CURABIS-STATE] ERGASTERION_RULING: PROCEED_WITH_CHANGES — hide the
|
||
exchange-rate lookup behind an interface before implementation — 2026-08-03, mid
|
||
|
||
al-review's Titus checklist reads this checkpoint back and treats an
|
||
unaddressed required change as a BLOCK finding — see `al-review.agent.md`.
|
||
|
||
## PTE format — a tagged comment per transition
|
||
|
||
Write one `[CURABIS-STATE]` comment per transition via `Create_TaskComment_PAG6102902`
|
||
(new) or `Modify_TaskComment_PAG6102902` (correcting the same transition, never
|
||
silently editing history — see Anti-Pattern). Keep it one line, machine-parseable:
|
||
|
||
[CURABIS-STATE] RED_CONFIRMED — 2026-08-03, mid
|
||
|
||
To resume: call `List_TaskComments_PAG6102902` scoped to `projectNo` +
|
||
`subTaskNo`, filter for `[CURABIS-STATE]` lines, the last one is current
|
||
state. Never infer state from `gitHubDevStatus` alone — that enum only has
|
||
four values (Backlog/In Progress/Done/On Hold) and cannot distinguish
|
||
"red confirmed" from "green confirmed" from "blocked in review".
|
||
|
||
## AppSource format — a checklist in the PR description
|
||
|
||
Open the PR as a draft at the start gate (not when work is ready), title and
|
||
branch as normal, description containing:
|
||
|
||
## CURABIS Task State
|
||
- [x] Branch created — 2026-08-03, mid
|
||
- [x] Test written, RED confirmed — 2026-08-03, mid
|
||
- [ ] Implementation
|
||
- [ ] Test GREEN confirmed
|
||
- [ ] Independent review (al-review)
|
||
- [ ] Merged
|
||
|
||
Update via `gh pr edit --body`, checking boxes as gates pass — never remove
|
||
or reorder completed lines, only append the next checked box. To resume:
|
||
`gh pr view <number> --json body` and read which boxes are checked.
|
||
|
||
## Why not adopt a dedicated session-state tool
|
||
|
||
The community pattern this generalizes from (`workflow_start`/`workflow_next`/
|
||
`workflow_status`, etc.) has real persisted, queryable state — genuinely
|
||
worth having — but enforces **no gating whatsoever**: the tool hands back a
|
||
natural-language instruction and trusts the calling agent to follow it, with
|
||
no human checkpoint anywhere in the mechanism. CURABIS's actual advantage is
|
||
the opposite property — RED_CONFIRMED and BLOCK are hard stops, not
|
||
suggestions (`[[testcase-must-fail-before-implementation]]`). Building a
|
||
parallel state store without also rebuilding that discipline would trade a
|
||
real strength for a shinier mechanism. This rule adds the persistence
|
||
without touching the gating.
|
||
|
||
## Anti-Pattern
|
||
|
||
// WRONG: editing a state comment's text after the fact to "fix" the record
|
||
Modify_TaskComment_PAG6102902(commentId, "[CURABIS-STATE] GREEN_CONFIRMED — 2026-08-03")
|
||
// on a comment that previously said RED_CONFIRMED — this destroys the
|
||
// audit trail. Append a new comment for the new state; only use Modify
|
||
// to correct a typo in the SAME transition, never to change which
|
||
// transition it records.
|
||
|
||
## Scope
|
||
|
||
Applies to every task on every CURABIS-owned or customer repo, PTE and
|
||
AppSource alike, from the moment `[[development-requires-bc-task]]` or the
|
||
AppSource equivalent activates. Wired into Smiley's Task Lifecycle gates —
|
||
see `smiley.agent.md`.
|