fix(apis): tell Cicada that spec [BLOCKING] markers are build requirements - #368
fix(apis): tell Cicada that spec [BLOCKING] markers are build requirements#368markmhendrickson wants to merge 1 commit into
Conversation
…ments Lens agents write `[BLOCKING]` / `[NON-BLOCKING]` review vocabulary into the assembled build spec. The swarm-wide prompt defines `[BLOCKING]` as "the author must address them", and Cicada's own prompt says to raise a checkpoint rather than open a PR when blockers exist. Cicada IS the author — so a spec containing those markers makes refusing-to-build the *compliant* reading. It was not malfunctioning; it was following the prompts. Evidence: across ten auto-build handoffs, the only two that ever opened a PR (neotoma#1882, #1963) are the only two whose specs contain ZERO blocking markers. All eight failures carry one to four. The markers are frequently conditional and not real blockers — e.g. "flag as [NON-BLOCKING] for this PR ... but if `regex` is ever exposed on a guest surface this becomes [BLOCKING]" — which to a builder scanning for its blockers reads as an open one. This is the smallest of the three options in ateles#359: disambiguate at the point of use rather than stripping severity signal from specs (option 2) or splitting the vocabularies across every lens prompt (option 3). The build prompt now states that markers inside the spec are definition-of-done items for the PR being opened, that conditional markers are forward-looking unless the condition holds, that pre-impl gates are already green, and that a checkpoint is for being unable to implement at all — not for the word "blocking" appearing. Signal is preserved: the spec's markers still reach the builder unmodified. The regression test discriminates — removing the added block makes it fail. 489 tests pass across the apis suites. Verification of the actual behaviour requires a live dispatch against one of the failing issues once this deploys; a green suite only proves the prompt says what we intend, not that the builder now builds. Closes #359 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Loxia Review 🪶Verdict: APPROVE SummaryFocused two-file change that adds a disambiguation paragraph to Cicada's build prompt so Findings
Nice touch: the test asserts the spec's own Loxia automated review · commit f215459 |
|
🤖 Lanius — Ateles swarm, PR gate inheritance Triage & Gate-Status BoardParent issue: #359 ( No Neotoma Gate status (workflow_type:
Owner: current_owner → Vanellus (Phase 4, pr_review gate). Vanellus: please pick up review of this PR. Labels: none applied (label application not in scope for PR-opened protocol).
All pre-impl gates (pm/ux/arch) satisfied → PR gate inheritance is clear. Full issue pipeline (expectations + Pavo) can be backfilled via 📎 Neotoma: ateles#359 |
2 participants
Closes #359
Root cause
Cicada was not malfunctioning — it was complying with the prompts.
Three facts compose into a refusal:
[BLOCKING]/[NON-BLOCKING]review vocabulary into the assembled build spec.[BLOCKING]as "the author must address them."Cicada is the author. Given a spec containing those markers, reporting instead of building is the specified behavior.
Evidence
blockingmarkers in specThe only two successful builds in the log are the only two specs with zero markers.
The markers are often conditional and not real blockers. Verbatim from a failing spec:
To a builder scanning for its blockers, a forward-looking note that names both tokens reads as an open
[BLOCKING].Change
Adds a
READING THE SPEC — severity markersblock to_cicada_build_prompt, stating that markers inside the spec are definition-of-done items for the PR being opened, not findings that withhold it; that conditional markers are forward-looking unless the condition holds today; that pre-impl gates are already green; and that a checkpoint is for being unable to implement at all, never for the word "blocking" appearing.Signal is preserved — the spec's markers still reach the builder unmodified.
This is option 1 of the three in #359: disambiguate at the point of use. Option 2 (strip markers at assembly) risks losing genuine severity signal; option 3 (split the vocabularies) is more correct but touches every lens prompt. Starting small and verifying by effect.
Verification — and its limits
origin/main.Being explicit about what this does not prove: a green suite shows the prompt says what we intend, not that the builder now builds. Per
fixed_means_behavior_verified_not_contract_accepted, real verification is a live dispatch against one of the failing issues after this deploys — a PR that actually appears.That verification is currently blocked: the daemon runs from a deploy checkout whose auto-deploy is failing (
deploy HEAD has diverged from origin/main), so merged fixes are not reaching the running daemon. Flagged to the operator separately.Related
🤖 Generated with Claude Code