Skip to content

claim/implement: read the rigor:* label and announce the resolved caps — the rung is documented but unread #437

Description

@evanharmon1

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 in
evanharmon1/harmon-init#804) moves the dev-loop round caps into .devflow.toml as rigor tiers and
states this resolution order in AGENTS.md:

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.
  • Never self-apply a rigor:* label. It is a human input; an agent reads
    it. (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 the
criteria 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.md

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions