feat(propensity): add the repair channel — the loop's third action

[stranske]

Stacked on #64 (base is claude/propensity-defect-finds; retarget as #61 and #64 merge).

Why

The loop has exactly two actions — promote (widen a binding) and demote (narrow one) — and
therefore cannot represent "this capability is worth having and is broken." The only available
response to a broken capability was to stop offering it, which silences the thing that should be
fixed and loses a capability worth keeping.

The live case. repo-playbook sits at 0.500 with one useful and one not-useful verdict, and the
Fine-Art-Archive audit documented why: its useful content is gated behind
task_type: implement/testgen/mechanical, so a review consult receives 308 characters, one
clause of which is factually wrong — it tells auditors a repository's default branch is something
it is not. Demotion silences that. A repair proposal names it, with the words attached.

Two inputs

1. not_useful verdicts, with their evidence carried forward. That is the whole difference
   between a flag and a repair: "0.5, one bad verdict" is a number; "308 characters, one clause
   factually wrong about the default branch" is an action.
2. Declines whose kind indicates a defect — decline_kind_repairable: wrong_match (the matcher
   may be wrong) and precondition_unmet. Explicitly not no_landing_zone: nobody's fault, the
   match was correct, the capability is working, and proposing a repair there asserts a defect that
   does not exist. scope_too_small is also excluded — for an arithmetic reason rather than a
   judgement: its fix is narrowing the declaration, which is the demotion path, and one decline
   must not argue for unbinding and rebuilding at once.

repairable is a second property of the kind, declared once beside demotable and read by one
lookup. They are independent questions, and the pair that proves it is precondition_unmet: not
demotable, is repairable. Before this channel existed that kind had no action at all — 11 of them
on the live ledger, recorded and inert forever.

Latched-gate check, in writing

1. What decrements it? record_repair — a named mechanism writing a durable marker with the fix
   and its artifact, after which a proposal counts only defect evidence newer than that marker.
   Not "time passes", not "someone notices". Window expiry is a second drain on the same
   WINDOW_DAYS constant. The first draft had no marker at all: defect evidence stayed in the
   90-day window, so fixing the capability did not clear its proposal for three months. That is the
   latch, and asking question 1 — not testing — is what caught it.
2. Can that mechanism run while the gate is non-empty? Yes, unconditionally. record_repair
   requires nothing a standing proposal forbids, and a proposal is report-only on both sides: it
   never withholds the capability from rank(), never lowers its propensity, never blocks a
   consult. The capability keeps being offered and keeps earning verdicts while the proposal stands.
3. Does the measuring window equal the draining window? Yes, by construction — WINDOW_DAYS,
   the one constant usefulness(), propensity() and surface_decline_counts() already share,
   bounds both the defect evidence counted and the repair markers that clear it. One name; a matching
   pair of literals would drift.

Runtime rule: every proposal carries defect_evidence_total (measuring),
defect_evidence_since_repair (blocking) and repairs_recorded (drainable), and report() carries
repairs_recorded even when the proposal list is empty — an empty list cannot say whether
anything is accumulating.

And the tie-break fails toward motion: ledger timestamps are second-granular, so freshness
compares >=, not >. A defect recorded in the same second as a repair is unorderable and must
re-open the proposal (one report line) rather than vanish (the finding). Asserted directly, on a
capability created for that assertion alone.

Human involvement

Zero. Report-only, never applied, and it queues nothing for anyone (CLAUDE.md §3). Proposals
are a field in a report the cadence step already writes: nothing waits on a human, nothing expires
against a human, no human action can fall behind. The live ledger produces 13 rows requiring
zero actions, expiring on their own with WINDOW_DAYS — 0 minutes/week. Every proposal
carries auto_applied: false and queued_for_owner: false, asserted.

What this deliberately does NOT do

• It never applies a repair, opens an issue, or queues anything for the owner.
• It does not touch any posterior — asserted before and after calling propose_repair.
• worth_having is reported, never a filter. Filtering on it would hide the
  broken-and-unwanted population, which is the demotion path's business; both readings must stay
  visible because they imply different work.

Live output

repair proposals — 13 (5 worth having and broken). REPORT ONLY: never applied, never queued.
  ~ offload                    WORTH HAVING  basis=declined_repairable defect=6/6 repairs=0
  ~ frontend-verifier          WORTH HAVING  basis=declined_repairable defect=4/4 repairs=0
  ~ adversarial-review         WORTH HAVING  basis=declined_repairable defect=2/2 repairs=0
  ~ repo-playbook              WORTH HAVING  basis=declined_repairable,not_useful_verdict defect=2/2
      Queried repo_knowledge.context_for(... task_type="review") and got 308 chars that changed …
  ~ deliberate-break-verifier  WORTH HAVING  basis=declined_repairable defect=1/1 repairs=0
  … 8 more with no useful verdict yet (cross-repo-coordination, capability-activation-audit,
    capability-firing-monitor, codemod-campaign, switch-review, testgen-lane, feature-scan,
    partitioned-review)

Break → revert (six, each confirmed to discriminate on a named assertion)

Break	Assertion that fails
no_landing_zone made repairable	"correct-match" not in props — a correct match gets proposed
precondition_unmet made non-repairable	"precondition-only" in props — the kind with no other channel goes silent again
repair marker dropped from the freshness test	"worth-fixing" not in drained — the latch
record_repair artifact guard dropped	"an unevidenced repair must be refused"
carried-forward evidence dropped	the factually wrong evidence assertion — the proposal becomes a flag
worth_having used as a filter	"precondition-only" in props

Verification

python3 capability_propensity.py --selftest passes (seven selftests, including the new
_selftest_repair). python3 verify.py re-run on the stacked tree; bash -n orchestrate.sh clean.
No new pytest tests, so .verify-floor.json is unchanged.

Docs updated in the same change per the ARCHITECTURE.md contract, plus README.md and the
orchestrate.sh cadence step (which now prints the provenance mix and the repair/find counts).
Dedup finding recorded in the capability-propensity ledger notes.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e3034730-bfe1-43b0-87c8-bc8bda3465e9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[stranske-keepalive]

Workflow source needed

PR #65 needs either a linked GitHub issue or one valid non-issue Workflow Source before PR metadata automation can manage it safely.

Please do one of:

• Add <!-- meta:issue:123 --> or a normal Closes #123 / Related to #123 line.
• Check one Workflow Source option in the PR body.
• Add a hidden marker such as <!-- workflow-source:local_request -->, <!-- workflow-source:manual_remote -->, <!-- workflow-source:review_followup -->, <!-- workflow-source:sync_campaign -->, or <!-- workflow-source:dependabot -->.
• Add a workflow source label such as workflow:source-direct-pr, workflow:source-local-request, workflow:source-review-followup, workflow:source-sync, or workflow:no-automation.

Once a valid source is present, this warning will not be reposted.

[agents-workflows-bot]

Automated Status Summary

Head SHA: 266f59d
Latest Runs: ⏳ pending — Gate
Required: core tests (3.12): ⏳ pending, core tests (3.13): ⏳ pending, docker smoke: ⏳ pending, gate: ⏳ pending

Workflow / Job	Result	Logs
(no jobs reported)	⏳ pending	—

Coverage Overview

• Coverage history entries: 0

Updated automatically; will refresh on subsequent CI/Docker completions.

---

Keepalive checklist

Scope

No scope information available

Tasks

• No tasks defined

Acceptance criteria

• No acceptance criteria defined

[stranske]

Runner dispatch state for autofix on PR #65. Do not edit.

[stranske]

Runner dispatch state for codex on PR #65. Do not edit.

[github-actions]

Workflow state fingerprint for Agents Gate Followups. Do not edit.

[github-actions]

Workflow state fingerprint for Keepalive Loop Reporter. Do not edit.