Skip to content

EPIC S3 standing: Debt Ratchet #3997

Open
4 of 8 issues completed
Open

Description

@noahgift

owner: aprender-df (re-owned 2026-10-09 by clerk aprender-3e for cop aprender-13: holds the parked #2378 fixup, the only child with live work)

Spec: APR-EPIC-001 §2 · Epic: S3 · Train: standing · Successor at cut: —

Theme

Debt Ratchet

done_when

clippy member baseline → 0 by 0.74; .unwrap() sites → 0; binary debt ledger falls; coverage floor ratchets up.

Budget

At most 3 open children (docs/roadmaps/epics.yaml). Repo-wide cap 100 open issues; andon at 95.

Absorbs

#4057, #2814, #2582, #2373

Prior body

Operator declaration (verbatim, 2026-09-23)

lets also declear a "rachet" to clean up technical debt lets assume 5 releaes to clear up 80% of debt. The issues; Code coverae needs to be closer to 95%, and we can use YOGA nightly CUDA coverage sharded, etc. B. we need actual "pv" contract enforcement at deepest level. C. We need to merge in the pv ontology spec fully. D. we need to purge the backlog of branches, tickets, pull requests and have all open tickets assigned to a release number. the unassigned queue is not allowed anymore, and open/stale pull requests are not allowed. First quorum research this, then apply in equal portions to .70, .71, .72, .73. .74

The ratchet

Five releases, 0.70.0 → 0.74.0, clear ≥80% of the measured debt, in equal portions (~16% of the baseline per release). Each release's gate refuses a regression below the previous release's level. It's a ratchet, not a target.

Pillar Baseline (to measure) Ratchet end state (0.74.0) Notes
A. Coverage 88.78% line (coverage-nightly 2026-07-29, COV_FLOOR := 88) ~95% line CUDA code is dark on CPU CI: use yoga nightly CUDA coverage, sharded (plus gx10 and lambda), merged into one report. Floor rises by equal steps per release
B. pv enforcement at the deepest level to measure: contracts with placeholder preconditions, #[contract] density, obligations with no falsifier contracts bind at the function (#[contract]), and pv gates run on every PR see Rule 7: coverage and contracts co-evolve
C. pv ontology spec (ONT-001) fully merged 13/27 rows bound (48%) per infra-83, infra main 29a84779d 27/27 bound (+ ONT-4c5) the spec lives in paiml/infra; aprender rows are bound through the ledger
D. Zero backlog 715 open issues (121 with no milestone, 298 in backlog), 57 open PRs, 3,328 local branches, 646 worktrees, 2,594 remote branches (2026-09-23 09:50Z) every open issue carries a release milestone; no unassigned queue; no stale PRs; merged/dead branches purged new rules: an issue with no milestone is refused (triage gate), and a PR idle > N days is refused (stale-PR gate)

Step 1: quorum research (before applying)

The quorum answers, with evidence:

  1. The measured baseline for each pillar (commands, not quotes).
  2. What "80% of debt" means per pillar, as a countable unit.
  3. The per-release slices (equal portions across 0.70–0.74), each with its gate and threshold.
  4. The yoga/gx10/lambda sharded CUDA-coverage design (runtime, shard count, merge method, GPU-lock interaction; see paiml/infra#1146).
  5. The new refusal gates for pillar D (the unmilestoned issue, the stale PR), including a first-green proof.

Step 2: apply

A child issue per (pillar × release), milestoned 0.70.0–0.74.0, after operator review of the quorum's plan.

Parked

Closed over budget (APR-EPIC-001 rule 5). Reopen = pull (rule 7).

Superseded epics

Activity

  1. noahgift commented on Sep 23, 2026

    @noahgift
    ContributorAuthor

    Operator 2026-09-23: "ALL releases in .7 have some rachet". The ratchet applies to EVERY 0.7x release, 0.70.0 through 0.75.0 (and any later 0.7x). The ≥80%-by-0.74 target stands; 0.75 carries a 6th slice (no regression, continued paydown). Each release's gate refuses a level below the previous release's.

  2. noahgift commented on Sep 23, 2026

    @noahgift
    ContributorAuthor

    Step 1 done: the quorum-researched plan is ready for operator review (PR #4003)

    Plan: docs/specifications/DEBT-RATCHET-001-070-074.md on #4003. Every number comes from a command listed in its §7 (2026-09-23, aprender main @ 49fe19c28, infra @ 29a84779). Nothing is applied. No child issues, milestones, closes, or deletes.

    1. Baselines (measured; three differ from this issue's table)

    Pillar Measured Note
    A 88.20% (810,420/918,869), last green on 08-29 This issue says 88.78%, which is stale. coverage-nightly: 0 green in 25 days (a timing test panics under llvm-cov). The integer COV_FLOOR=88 missed a 0.58 pp drop. The regex keeps 415k lines out of the denominator, all of apr-cli among them
    B 219/3,250 equations bound; 510 call sites: E0 = 267, E1 = 128, E2 = 115; 19 contracts with obligations but no falsifier pv lint contracts/ is reachable from no workflow
    C 13/27 rows bound (14 unbound: 12 aprender, 1 infra, 1 pmat) matches infra-83
    D 428/723 open issues not in a release milestone; 19 stale PRs; 353 live remote branches (297 with no PR); 3,334 local branches; 651 worktrees (44 GB) This issue says 2,594 remote branches; git ls-remote gives 353

    Two facts reshape D. Unmilestoned issues are inflow: all are under 5 days old, at about 70 issues a day, so the gate has to be at intake. And updatedAt cannot detect a stale PR: no PR is idle over 7 days by that field, yet 20 are older than 7 days, because update-branch merges keep refreshing it.

    2 and 3. Units and slices (floor = B ∓ k·⌈slice⌉; each release also refuses anything worse than the previous tag)

    unit 0.70 0.71 0.72 0.73 0.74
    A P₀ line coverage, bp (pinned regex and pinned file list) 8,928 9,037 9,146 9,255 9,364
    B-1 E2 call sites (total call sites never fall) 179 243 307 371 435
    B-2 contracts with no falsifier 15 11 7 3 0
    C ONT rows bound (the selector picks rows live) 16 19 22 24 27
    D-1 issues outside an open release milestone 342 256 170 84 0
    D-2 stale PRs 15 11 7 3 0
    D-3 remote branches with no PR 237 177 117 57 0

    C and D go to 100%, because the operator's words for them are absolute. The plan does not quote a B-3 figure (bound equations, 485 per release on the full denominator) as credible; it is flagged for operator decision 3.

    4. CUDA coverage (sharded, yoga-first)

    • Build outside the GPU lock. paiml/infra#1146 measured compile time spent under the lock.
    • One gpu-q --prio 1 per nextest partition. The shard is a plain nextest command; lock-taking scripts are never wrapped.
    • N = ⌈T_instr / 10 min⌉. T_instr is [U] until the first unsharded run after the 0.69.1 freeze. The estimate is 4–8 shards for serve alone.
    • Merges: profdata within a host; an LCOV union at one pinned SHA across hosts (LF = union, LH = hit anywhere, per-host figures printed).
    • Hosts: yoga (idle sm_89) is primary and gx10 covers ARM/sm_121. lambda runs only by operator call.
    • P_cuda is its own ratchet. Because its baseline first exists at 0.71, it reaches only 3/5 of its slices by 0.74 (decision 7).

    5. Pillar-D gates

    New predicates R6 (unmilestoned issue > 24 h, and an old or closed release milestone does not count) and R7 (PR > 7 d with no author activity in 72 h, where update-branch merges are not activity) in the existing T-5 check_reconcile.sh. They run in ratchet mode, so they are green on the real repo from day one, and are armed at zero at 0.74. No first-green proof has run yet, because the predicates do not exist. The step-1 counts they will first read are 428 and 19. The live --max N / --max N-1 proof and the case tables are the acceptance tests of step 2.

    Quorum

    A grillme quorum of width 3 returned 2× PASS-with-changes and 1× PASS. I applied 14 must-fix items; the table is in plan §9. I refuted one: an empty coverage figure already fails closed. Advisory only: all three lanes are gemini (the gpt-oss seat hit a 429 with a 95 h reset), and every lane exited 3 because other sessions changed shared refs during the run, not because a lane wrote anything.

    Operator decisions (plan §6)

    1. Pillar A needs about 10k covered lines per 3-day release. Keep that pace, or slice by time?
    2. Keep the 415k-line exclude regex (gate P₀, report P_full), or gate its shrinkage?
    3. B-3 denominator.
    4. Confirm D goes to zero.
    5. What "refused" means (proposed: a T-5 failure; never an automatic close).
    6. 0.70.0 carries 176 issues and is due 09-26. Should triage move them forward?
    7. Should P_cuda's window run to 0.76?

    Step 2 (child issues per pillar × release) waits for your approval.

  3. added this to the 0.70.0 milestone on Sep 23, 2026
  4. noahgift commented on Sep 23, 2026

    @noahgift
    ContributorAuthor

    milestone → 0.70.0 per docs/roadmaps/milestone-triage-2026-09-23.md (#4024), operator approval 2026-09-23 (relayed by aprender-cf). Reason: the ratchet epic spans 0.70-0.74; keep on 0.70.0 as its first slice

  5. removed this from the 0.70.0 milestone on Sep 23, 2026
  6. noahgift commented on Sep 23, 2026

    @noahgift
    ContributorAuthor

    milestone REVERTED to none (its state before #4024's move). The quorum on #4024 found this issue is named as must-carry by #3998, #4000, #3999, #4001 and #4002, and the table's own rule says such an issue is an operator DECIDE, never placed by the author. It was moved in error. It is now listed on #3998 as a pending decision: 0.70.0 first slice (recommended). No new placement was made.

  7. added this to the 0.70.0 milestone on Sep 23, 2026
  8. noahgift commented on Sep 23, 2026

    @noahgift
    ContributorAuthor

    triage 2026-09-23 (aprender-dd, standing triage owner): milestoned to 0.70.0, theme Fast Train (CI, gates, pv, release tooling, hygiene); it had no release milestone. Decision still pending (#4024 recommends 0.70 as its first slice; #3998/#4024 DECIDE row): this milestone is a placeholder until the operator rules.

  9. modified the milestones: 0.70.0, 0.70.1 on Sep 25, 2026
  10. noahgift commented on Sep 25, 2026

    @noahgift
    ContributorAuthor

    Moved 0.70.0 → 0.70.1 per the cop ruling on the 0.70.0 burndown (aprender-77, 2026-09-25). This issue is not on the critical path of any 0.70.0 gate (ONT-001, all [[bin]]s #4189, discharge --strict, merge-back #4338). Burndown: /mnt/nvme-raid0/cop-inbox/aprender-ea-070-burndown.md — aprender-ea

  11. 25 remaining items

  12. modified the milestones: 0.71.0, 0.73.0 on Oct 14, 2026
  13. noahgift commented on Oct 14, 2026

    @noahgift
    ContributorAuthor

    Folded into this epic's checklist from #4153 (same theme; text kept verbatim; owner owner:aprender-a7 keeps the work).

    Original text of #4153

    Clippy tech-debt ratchet, slice for 0.70.0. Filed by the cop (aprender-cf) on the operator's instruction, verbatim, 2026-09-24: "move those issues into our next 5 release technical debt rachet and split evenly".

    Baseline: measured by aprender-30 (#4152) on main aa7c6ef with cargo clippy --workspace --all-targets --no-deps -- -D warnings (GPU trio excluded, as CI does): 3807 diagnostics in 15 crates. #4152 removes the 1280 aprender-serve excessive_precision findings (mirroring the workspace allow) and installs the member-wide ratchet (keyed on crate × target-kind × lint; only decreases allowed). That leaves 2527, split into five roughly equal slices over 0.70–0.74.

    This slice (0.70.0): apr-cli (284) + aprender-core (218) + aprender-serve residual after #4152 (~20).

    Done when:

    Sequence: 0.70 ≤2005 → 0.71 ≤1445 → 0.72 ≤886 → 0.73 ≤376 → 0.74 = 0. Depends on #4152.

    Collapsed rows (APR-EPIC-001 rule 20)

    One issue per PR: tick a line when its PR merges; the PR closing the last line says Closes #4153, the others Refs #4153 row <id>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicEpic — multi-story umbrellaowner:aprender-wcensusowner session aprender-wcensus

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions