You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A resolution rung that policy documents must be readable by the tools that do
the resolving. A documented input no tool reads is not a feature with a missing
implementation — it is an instruction that silently does nothing, and it reads
to a human exactly like one that works.
explicit instruction in the session
> a rigor:* label on the issue
> default_rigor
> a built-in 4 / 4 / 4 if the file is absent
The middle rung is inert end to end:
No skill reads it. Neither /claim nor /implement looks for a rigor:* label, so an agent picking up an issue resolves default_rigor
regardless of how the issue is labelled.
No repository has the labels.setup-github-labels.sh seeds rigor:light|standard|deep as of that PR, but the script is only re-run
deliberately; no repo has been provisioned, so there is currently nothing to
read even once a skill reads it.
The consequence is not a broken build — it is worse. A human labels an issue rigor:deep expecting five challenge rounds, the agent runs three, and
nothing anywhere reports a discrepancy. The label looks applied, the work looks
done, and the budget silently was not what the label asked for.
What the skills must implement
The rules are already specified in harmon-init's AGENTS.md; this is about
honouring them, not inventing them:
Per-stage maximum across every rigor:* label present — labels are
multi-select, and resolving per stage means a conflict can only ever buy more
review, never less, with no tier ranking to agree on.
Ignore an unknown value. A rigor: label naming no tier in the file is
ignored, never guessed at.
Merge-base resolution when .devflow.toml is in scope of the change,
so a branch cannot lower the gate it is itself editing.
Announce the resolved caps on entering the loop, and carry them into the
PR body — naming a tier only when one tier supplied all of them.
State any cap below default_rigor in the announcement and PR body, so a
reduced budget is visible to the human reviewer rather than silent.
The label-creation half is an operator step in the consuming repo
(task setup:github-labels), not work for this repo; it is listed in the
criteria only so the rung is not declared done while nothing can carry it.
No matches means the rung is unread and every change silently resolves default_rigor. Resolved when both skills resolve and announce the caps.
Acceptance criteria
/claim resolves rigor:* from the issue and announces the resolved caps
/implement does the same when it enters the dev loop without a prior claim
Resolution is per-stage maximum across all present labels; unknown values are ignored
The merge-base rule is honoured when the change edits .devflow.toml
A cap resolving below default_rigor is stated in the announcement and the PR body
Neither skill ever applies a rigor:* label to its own issue
Behaviour is unchanged where no .devflow.toml exists or no rigor:* label is present — default_rigor, else the built-in fallback
The labels are provisioned on at least one live repo, so the rung is exercised rather than only implemented
Found while doing evanharmon1/harmon-init#808 — filed here because this repo
owns /claim and /implement; harmon-init only vendors them. It was named as
follow-up work in that PR's body and nowhere else, which stopped being a record
the moment the PR merged.
Invariant
A resolution rung that policy documents must be readable by the tools that do
the resolving. A documented input no tool reads is not a feature with a missing
implementation — it is an instruction that silently does nothing, and it reads
to a human exactly like one that works.
Current violation (observed 2026-08-12)
evanharmon1/harmon-init#808 (merged to
main; release 4.29.0 pending inevanharmon1/harmon-init#804) moves the dev-loop round caps into
.devflow.tomlasrigortiers andstates this resolution order in
AGENTS.md:The middle rung is inert end to end:
/claimnor/implementlooks for arigor:*label, so an agent picking up an issue resolvesdefault_rigorregardless of how the issue is labelled.
setup-github-labels.shseedsrigor:light|standard|deepas of that PR, but the script is only re-rundeliberately; no repo has been provisioned, so there is currently nothing to
read even once a skill reads it.
The consequence is not a broken build — it is worse. A human labels an issue
rigor:deepexpecting five challenge rounds, the agent runs three, andnothing anywhere reports a discrepancy. The label looks applied, the work looks
done, and the budget silently was not what the label asked for.
What the skills must implement
The rules are already specified in harmon-init's
AGENTS.md; this is abouthonouring them, not inventing them:
rigor:*label present — labels aremulti-select, and resolving per stage means a conflict can only ever buy more
review, never less, with no tier ranking to agree on.
rigor:label naming no tier in the file isignored, never guessed at.
.devflow.tomlis in scope of the change,so a branch cannot lower the gate it is itself editing.
PR body — naming a tier only when one tier supplied all of them.
default_rigorin the announcement and PR body, so areduced budget is visible to the human reviewer rather than silent.
rigor:*label. It is a human input; an agent readsit. (Its trust model is weak on its own — rigor:* labels are honoured without verifying who applied them — triage can lower the review budget harmon-init#809 tracks
that the setter is not verified — so do not build anything here that assumes
the label is authenticated.)
The label-creation half is an operator step in the consuming repo
(
task setup:github-labels), not work for this repo; it is listed in thecriteria only so the rung is not declared done while nothing can carry it.
Verify
grep -rn 'rigor' ai/skills/universal/claim/SKILL.md ai/skills/universal/implement/SKILL.mdNo matches means the rung is unread and every change silently resolves
default_rigor. Resolved when both skills resolve and announce the caps.Acceptance criteria
/claimresolvesrigor:*from the issue and announces the resolved caps/implementdoes the same when it enters the dev loop without a prior claim.devflow.tomldefault_rigoris stated in the announcement and the PR bodyrigor:*label to its own issue.devflow.tomlexists or norigor:*label is present —default_rigor, else the built-in fallbackFound while doing evanharmon1/harmon-init#808 — filed here because this repo
owns
/claimand/implement; harmon-init only vendors them. It was named asfollow-up work in that PR's body and nowhere else, which stopped being a record
the moment the PR merged.