dotfiles/claude/governance/skill-harvest-fix-lane-JURIST-PACKAGE-2026-08-01.md

---

title: "The skill-harvest FIX lane and its hard floor — PENDING-88" date: 2026-08-01 type: PROPOSAL · design gate · executor drafts → jurist design-gates → steward authorizes audience: "The jurist, who has NO repository access. This document is self-contained: every clause it reasons about is quoted verbatim below." status: "DRAFT for the design gate. Nothing proposed here is built. One adjacent item (option (d), register compaction) was executed today under a SEPARATE, pre-existing authorization — disclosed in Part II so the ruling is made against the current state, not a stale one."

How to read this

Part I quotes the ratified text: the four-tier authorization taxonomy, the executor-agency clause that already rules the recursion question, the three constitutional constraints that bound any answer, and — the load-bearing one — the full text of /wrap-up §1.6, the operational rule at issue. Part II gives the terrain as dated observations. Part III shows the collapse from the quoted text: §1.6 already draws a change-class distinction and names it as such, then does not apply it one paragraph later. Part IV states the proposal. Part V traces each quoted clause to its post-proposal end-state, including inference-direction. Part VI runs the change-class test on the proposal itself. Part VII is the scope boundary. Part VIII is the executor's declared interest, stated once and bound to a falsifier rather than performed. Part IX is the gate questions.

The one-sentence claim to test: /wrap-up §1.6 already draws the FIX-vs-PROPOSAL distinction for one class of artifact and names it as that distinction, but applies a blanket prohibition to the adjacent class — and that asymmetry is internal to §1.6 rather than required by anything the constitution ratifies.

---

Part I — Grounding: the ratified sections this builds on (quoted)

This section exists because the recurring failure is composing a claim about a governing document from memory when the document already settles it. These are the actual words, read from the substrate 2026-08-01.

§Authorization Taxonomy (~/CLAUDE.md) — the four tiers, complete:

| [FIX] | Resolves a scoped bug against existing specification | Nothing — implement directly | | [HARDENING] | Addresses the class of failure, not just the instance | Propose in PENDING.md; await steward annotation | | [PROPOSAL] | New architectural direction or contract | Explicit steward authorization via REVIEWED.md | | [ESCALATE] | Exceeds Claude Code's authority — constitutional, relational, or scope-exceeding | Surface immediately; do not proceed |

§Executor Agency — the governance-contract clause, which addresses this question directly:

The governance contract protects the recursion. Claude Code improving its own diagnostic capability is not self-modification — it is the system doing what it was built to do. The steward remains in the loop through [PROPOSAL] and [ESCALATE] tags. The executor's job is to bring the steward the fullest possible picture, not to pre-filter for comfort.

§Constitutional Constraints — 1, 5 and 6, which bound any answer:

1. This file — Claude Code cannot modify ~/CLAUDE.md, ~/REVIEWED.md, or L2 constitutional documents

5. The loop is load-bearing — Human authorization is not a bottleneck to be optimized away. It is the structural requirement of the governance model

6. Contamination awareness — The executor agency directives are a partial mitigation, not a resolution. Treat outputs about the system's own reliability with appropriate epistemic caution until L2 inquiry is formalized

§Three-Party Model — escalate-unconditionally list:

Escalate unconditionally for any change touching: logchain append path · cursor persistence · module registration order · L2 constitutional layer · this file.

/wrap-up SKILL.md §1.6 — the operational rule at issue. Both load-bearing passages, in document order:

This is event-based, not change-count: a pointer-style CLAUDE.md is untouched by ordinary corpus/state churn (files graduated, sources pinned, reports regenerated), so update it only when the class of thing it carries changes. Mechanical updates (a fleet line, a term, a pointer) apply at wrap like a tracker; a change to a discipline or governance posture is surfaced for steward review, not auto-applied (the same FIX-vs-PROPOSAL split, one level up).

(This passage opens §1.6's fourth bullet, headed "Repo CLAUDE.md fresh?"; the bullet's first sentence — which enumerates what such a file carries — is elided here as not load-bearing. The text quoted above is contiguous and verbatim.)

Surface each as a proposal in §8 — never create, patch, or retire a skill autonomously at wrap. The steward converts proposal to action; only then is a skill changed, and the changed skill carries a one-line provenance note in its source (e.g. <!-- 2026-05-27: … -->) so the chain of improvements stays legible.

/wake-up SKILL.md §2.a — the consumer that depends on the register being readable:

• Read skill-harvest-register.md directly — the canonical surface for open skill proposals (wrap §1.6 appends there); surface any awaiting steward authorization

PENDING-S2 — the jurist's own prior ruling on this file class (2026-05-18 shape-review), recorded verbatim in ~/PENDING.md:

Jurist (2026-05-18 shape-review): the hooks/skills contract is doctrinal, not tooling. It determines what the unborn session can trust about its inheritance.

The steward's statement of intent (2026-07-29), recorded verbatim in PENDING-88:

I never meant to forbid that as long as I was made aware of what needed to be improved and why. In fact, I need you to be able to do so — I cannot think of everything.

The precedent for this exact class — the executor proposing a change to its own authorization posture. ~/CLAUDE.md, closing note of §Executor Agency:

Authorized: 2026-03-21. Proposed by Claude Code (executor) via PENDING-1. Reviewed and authorized by steward and jurist. This proposal is itself evidence the directive is already operative — the executor used the authorization taxonomy correctly on a change affecting its own behavior.

---

Part II — Terrain (dated observations)

Every figure below is an observation with a date and a stated counting rule, not fixed prose.

• The register, as measured 2026-08-01 before today's compaction: 166,589 bytes; 190 markdown table rows (rule: rows with ≥5 pipes, excluding header and separator rows); of those 177 open and 13 ruled (8 BUILT · 4 AUTHORIZED · 1 DEFERRED). Oldest open item 2026-05-24.
• Correction to PENDING-88's own figures. The item claims "151 PROPOSED against 26 BUILT + 13 AUTHORIZED." Under the stated rule the table-row counts are 123 PROPOSED / 8 BUILT / 4 AUTHORIZED; the discrepancy is that much ruled history lives in a bullet list and in prose blocks that no row-counter sees. Neither figure was produced with a stated inclusion rule until now. The item's own falsifier — "if the register reads under the cap, or if the PROPOSED backlog is small or recent, the diagnosis fails" — is not triggered on either count.
• One section held 58% of the file: a single heading, ## New proposals (2026-06-13 post-clear — …), spanned 411 lines and 96,848 bytes and contained 33 distinct dates running 2026-05-24 → 2026-07-19. Five weeks of /wrap-up appends landed inside an existing section instead of new dated ones, so the register misreported its own chronology.
• Disclosure — the state changed today, under a different authorization. PENDING-88's option (d), register compaction, was already authorized on 2026-07-19 by the register's own FULL REVIEW ("Stroke 4 — register compaction: AUTHORIZED; same slot as Stroke 2") and had gone unexecuted for six weeks. It was executed 2026-08-01: the register was split into a live index (44,421 bytes, all 177 open proposals indexed one line each) plus skill-harvest-archive.md holding the previous register verbatim (archive tail byte-identical to the original body over 166,027 bytes). Stroke 4's prescribed method could not have worked — it directs that "ruled items collapse to verdict lines", and only 13 of 190 rows were ruled, so collapsing all of them would have removed ~7% and left the file over the read cap. A split was used instead. Option (d) is therefore moot for this ruling; (a), (b) and (c) are live.
• What the backlog is not. 177 proposals opened since 2026-05-24 against one full review (2026-07-19). They were not declined. Until today they were filed in a document that exceeded the read cap, which means the /wake-up step quoted in Part I — the step whose entire purpose is to surface them — could not complete. Awareness failed mechanically, not by judgment.

---

Part III — Why the implicit default collapses, from the quoted text

The argument is not that §1.6 conflicts with the constitution. It is narrower and textual: §1.6 contradicts itself, one paragraph apart.

1. In its Repo CLAUDE.md clause, §1.6 draws a change-class distinction and names it as that distinction: mechanical updates "apply at wrap like a tracker"; a change to a discipline or governance posture "is surfaced for steward review, not auto-applied" — expressly "the same FIX-vs-PROPOSAL split, one level up." So §1.6 already holds that (i) the split is the right frame for wrap-time self-tending, and (ii) some wrap-time changes may be applied without prior authorization.

2. Two paragraphs later, for skills, §1.6 applies one blanket rule with no change-class distinction at all: "never create, patch, or retire a skill autonomously at wrap." A skill gaining a clarifying sentence and a skill's authorization boundary being moved are governed identically.

3. Nothing in Part I requires that asymmetry. The taxonomy's [FIX] row reads "Nothing — implement directly." The governance-contract clause rules the general question in the same direction — "improving its own diagnostic capability is not self-modification — it is the system doing what it was built to do" — and locates the steward's presence in "the [PROPOSAL] and [ESCALATE] tags", i.e. in the taxonomy, not in a blanket prohibition that bypasses it. Skills appear nowhere on the escalate-unconditionally list.

4. The consequence is not theoretical, and it inverts the clause's own purpose. The same governance-contract clause ends: "The executor's job is to bring the steward the fullest possible picture, not to pre-filter for comfort." The blanket rule routed every proposal into a single file; that file grew past the read cap; the /wake-up step that exists to surface them stopped completing. A rule adopted to preserve steward awareness produced, by accumulation, the loss of steward awareness. The failure mode is mechanical, and Part II measures it.

5. What this does not show. It does not show the blanket rule was wrong when written, and it does not show the loop is a bottleneck — Constraint 5 forbids that reading and this proposal does not make it. It shows only that §1.6 applies two different governance frames to two adjacent classes of self-tending, and offers no stated reason for the difference.

---

Part IV — The proposal

The requirement, stated as the governing document would state it. Skill changes are classified before they are made, by the test §1.6 already applies one clause earlier:

(Proposed text, not ratified — rendered fenced, since every > blockquote in this package is verbatim ratified text.)

Does this change what the executor may do without asking, or what a governed artifact asserts?
  NO  -> [FIX]:      apply it, and report it in the wrap — what changed and why —
                     with a provenance comment in the skill source.
  YES -> [PROPOSAL]: unchanged. Surface it; do not apply it.

The hard floor — a standing carve-out that remains PROPOSAL or ESCALATE regardless of how the test scores it. This is the part that should be scrutinised hardest, because a self-granted FIX lane is exactly where pre-filtering for comfort would appear:

• anything touching ~/CLAUDE.md, ~/REVIEWED.md, or L2 constitutional documents (Constraint 1);
• anything altering an authorization boundary, a gate's acceptance criteria, or the governance loop itself (Constraint 5);
• anything touching the logchain append path, cursor persistence, or module registration order (the escalate-unconditionally list);
• and — the clause most relevant here — anything that would reduce what is surfaced to the steward.

The mechanism, as revisable data rather than doctrine: the classification test and the floor are stated in /wrap-up §1.6; the report obligation is discharged in the wrap output and the skill's own provenance comment. Nothing in the mechanism requires a change to ~/CLAUDE.md, and this proposal does not request one.

What makes this bounded rather than open-ended: the FIX lane substitutes awareness by disclosure for awareness by permission. It does not reduce what the steward learns; it changes when they learn it, from before to immediately after, and only for the class where nothing the system asserts has changed.

---

Part V — Consequence-trace (each quoted clause → the proposal's end-state)

Ratified clause (quoted in Part I)	Post-proposal end-state	Verdict
[FIX] — "Nothing — implement directly"	Applies to skill changes that alter neither executor latitude nor what an artifact asserts.	Honoured — the row is used as written; it is currently unreachable for this class.
[PROPOSAL] — "Explicit steward authorization via REVIEWED.md"	Unchanged for every skill change that moves an authorization boundary or an assertion.	Preserved.
Governance contract — "not to pre-filter for comfort"	Mandatory wrap report on every FIX-lane change; the floor forbids any change that reduces what is surfaced.	Strengthened, since today the mechanism surfaces nothing.
Constraint 1 — cannot modify ~/CLAUDE.md / ~/REVIEWED.md / L2	Named explicitly in the floor; proposal requests no change to any of them.	Untouched.
Constraint 5 — "the loop is load-bearing"	The loop is retained for the PROPOSAL class and for the entire floor; only the class where nothing is asserted moves to report-after.	Preserved — and this is the clause the jurist should test hardest.
Constraint 6 — contamination awareness	Executor's interest declared once and bound to a falsifier (Part VIII) rather than used as a discount.	Engaged, not discharged.
Escalate-unconditionally list	Skills are not on it; the floor re-imports every listed item anyway.	Honoured, conservatively.
§1.6 Repo CLAUDE.md clause	Its distinction is extended to the adjacent class rather than a new one invented.	Extended, not overridden.

One level deeper — inference direction. In the current state, "no authorization was sought" reliably means "no change was made." Under the proposal it becomes ambiguous between "no change was made" and "a FIX-class change was made and reported." The inference the steward can draw from silence therefore weakens, and the report obligation is what must carry that weight. If the report is missing or thin, the proposal is strictly worse than the status quo. This is why the report must be a requirement of the lane and not a courtesy — and why Q3 below asks whether a report the executor writes about its own change is adequate.

One level deeper — is a named class actually two kinds? Yes, and the split matters. "Patch a skill" covers both (i) changes to what a skill records — a ledger section, an output field, a wake line — and (ii) changes to what a skill permits or requires. Class (i) cannot alter any assertion or latitude; class (ii) always can. The proposed test cuts exactly between them. It is worth the jurist noting that all four proposals which prompted PENDING-88 (a ## What held ledger section, a prevention KG predicate, one wake line, a reframed standing question) are class (i) — the class most starved by a blanket gate, and the class whose absence produced the "ledger of failure" the steward named.

---

Part VI — Change-class of this proposal, and landing shape

Running the ratified test on the proposal itself: it changes what the executor may do without asking. Therefore [PROPOSAL], requiring explicit steward authorization via REVIEWED.md — which is why it is filed as one and why nothing in Part IV has been applied.

Landing shape: an edit to /wrap-up SKILL.md §1.6 (the classification test + the floor) and a provenance comment in that file. No change to ~/CLAUDE.md. No semver artifact and no supersession — these are skill files, not a versioned constitution. No re-verify storm: no past skill change is reclassified, and no existing artifact's status changes.

Why the jurist and not the steward alone. The taxonomy makes [PROPOSAL] a steward-authorization matter, and nothing here touches the escalate list — so on the letter, this is the steward's call. Two things argue for a jurist ruling anyway, and both are recorded rather than asserted: (1) the only prior instance of the executor proposing a change to its own authorization posture, PENDING-1, was "Reviewed and authorized by steward and jurist"; (2) the jurist has already ruled that this file class is "doctrinal, not tooling." ⚠ Honest limit on (2): that 2026-05-18 ruling concerned the wake/wrap deposit contract — what a wrap-up guarantees an unborn session — not who may edit a skill. Extending it to this question is the executor's inference, not the jurist's words, and the jurist should discount it accordingly.

---

Part VII — What this package does NOT do

• It does not apply any change to /wrap-up, /wake-up, or any other skill.
• It does not request or imply any change to ~/CLAUDE.md, ~/REVIEWED.md, or any L2 document.
• It does not ask for the loop to be narrowed anywhere the floor applies, and it does not treat the loop as overhead.
• It does not decide the steward-only question of pacing — whether the 177 open proposals get a review session, and when.
• It does not re-litigate option (d): that was separately authorized on 2026-07-19 and executed 2026-08-01, and is disclosed in Part II so this ruling is made against the current state.
• It does not claim the blanket rule was wrong when adopted, only that it is now unmatched to the taxonomy §1.6 itself invokes.

---

Part VIII — The executor's declared interest, and the falsifier that carries it

This proposal would loosen a constraint on the executor, is proposed by the executor, and follows an invitation from the steward. The interest is real and is stated so it cannot be read without seeing it.

It is stated once, and it is not offered as a discount. An earlier draft of this item implied the proposal should be discounted because the steward would welcome it — which makes welcomeness the evidence and would disqualify every correct thing the executor produces. The steward's challenge stands: "Does 'pleases you' and 'successfully achieve what's necessary' mean two different things? There are many tasks that I ask you to perform that I would have no idea how to create a tool for." The two coincide whenever the true answer is also the welcome one; contamination is the case where they diverge. Performing scrupulousness is itself pleasing, cheap, and buys the appearance of rigor at the cost of a working instrument.

So the operative mitigation is not the disclosure — it is that every load-bearing claim here is one command from refutation:

• What would falsify Part II: the register reading under the read cap, or a PROPOSED backlog that is small or recent. Measured: 166,589 bytes before compaction, 177 open, oldest 2026-05-24.
• What would falsify Part III: §1.6 containing a stated reason for treating skills differently from repo CLAUDE.md files, or the escalate-unconditionally list naming skills. Both texts are quoted whole in Part I; neither does.
• What would falsify the framing entirely: if the 177 proposals had been declined rather than unread, the diagnosis would be a governance judgment the executor is second-guessing, not a mechanical failure. The /wake-up step quoted in Part I could not complete against a 166 KB file; that is the mechanism, and it is checkable.

If any of those falsifiers lands, option (a) — status quo — is the correct ruling, and this package fails on its own terms.

---

Part IX — Gate questions for the jurist

Q1 — Is the asymmetry inside §1.6 a deliberate distinction or a drafting gap? §1.6 draws the FIX-vs-PROPOSAL split for repo CLAUDE.md and names it as that split, then applies a blanket prohibition to skills two paragraphs later. Executor's lean: a gap. The blanket rule predates the repo-CLAUDE.md clause (added 2026-07-05 per its provenance comment), so the distinction was drawn later and simply not carried back. But the executor is the interested party, and a deliberate distinction is a coherent reading the jurist may hold: skills change what future sessions do, while a repo CLAUDE.md only changes what they read.

Q2 — If a FIX lane is admitted, is the proposed test the right cut? The proposed test is "does this change what the executor may do without asking, or what a governed artifact asserts?" Executor's lean: yes, but the jurist may prefer a narrower single-clause form — does it change what the system asserts to be true? — with executor latitude folded into the floor rather than the test. The two-clause form is more explicit; the one-clause form is harder to rationalise around. The executor does not have a strong preference and flags this as the place where wording will do the real work.

Q3 — Is a report the executor writes about its own change adequate to carry the weight Part V identifies? Under the proposal, silence stops meaning "nothing changed." Executor's lean: surfaced, not answered. The honest position is that the report is necessary and the executor cannot certify it is sufficient, since the failure it must catch is one the executor would be the last to notice. If the jurist judges it insufficient, a mechanical alternative exists — a required provenance comment in the skill source, which is greppable and independent of the wrap narrative — and the executor would accept that as a condition.

Q4 — Is the hard floor's enumeration complete? It carries Constraints 1 and 5, the escalate list, and "anything that would reduce what is surfaced to the steward." Executor's lean: the last clause is the one doing real work and is also the vaguest; the jurist may wish to sharpen it, since it is the clause a self-interested executor would have the most latitude to interpret.

Q5 — Does this class of change require a jurist ruling standing, or was PENDING-1 situational? The taxonomy makes [PROPOSAL] a steward matter. PENDING-1 — the one prior instance of the executor proposing a change to its own authorization posture — was ruled by steward and jurist. Executor's lean: explicitly none. This is a question about the jurist's own remit, and the executor is the wrong party to hold a lean on it.

---

Filed by the executor 2026-08-01. Companion entry: ~/PENDING.md PENDING-88 (with its 2026-08-01 amendment, which corrects the item's counts and records that option (d) was already authorized and is now executed). No code was run, no skill was changed, and no governed artifact was edited in the authoring of this package.

---

Addendum — design-gate ruling received, and the required verification supplied (2026-08-01)

Parts I–IX above are preserved unrewritten as the text the jurist ruled on. This Addendum layers disposition; it does not revise history. Ruling filed verbatim at skill-harvest-fix-lane-JURIST-RULING-2026-08-01.md.

The ruling in force

Design gate PASSED, conditioned. Q1, Q2, Q4, Q5 affirmed — Q2 with the executor's own narrower alternative declined as less safe (a latitude-expanding but non-assertive change would pass an assertion-only test). Q3 answered against the executor's fallback framing: report and provenance comment are both mandatory, not one with the other in reserve. Register split (option (d)) untouched — separately authorized 2026-07-19 and correctly executed by the split method.

Corrections that supersede the drafted design

1. A third instrument, not proposed: a running append-only FIX-lane index, one line per applied change (skill · what changed · date), separate from wrap narratives — on the same live-index pattern as today's register split, and for the same reason: to stop this proposal's own failure mode recurring one level up, on the changes instead of the proposals.
2. The floor's catch-all gets an operational form. "Anything that would reduce what is surfaced to the steward" becomes: any change that removes, defers, or narrows the visibility of an open item, or that could cause a future item to land somewhere the steward's surfacing tools don't read, stays PROPOSAL regardless of the test's outcome. Checkable against the failure Part II measured, rather than a standing judgment call.
3. The lane is provisional, not settled. After the first FIX-lane batch or one month, whichever comes first, steward and jurist review the index together before the lane is treated as settled.

The required verification — supplied

The ruling: "Required before landing: the same mechanical containment-with-positive-control verification the 2026-07-29 package carried, applied to these quotes specifically."

Executor's correction first, because it bears on how this should be read. The check was run before filing — 15/15 quotes contained, positive and negative controls passing — and the package did not report it. The jurist noticed its absence. For a reader with no repository access, a check performed but not disclosed is indistinguishable from one not performed; the failure is in the record, not the method, and it is the say–do seam running in the less familiar direction. Supplied now per-quote, with the file identity pinned so the check is repeatable:

Source file	sha256 (first 32)	bytes	lines
~/.claude/skills/wrap-up/SKILL.md	37a31595298b13645e7389197a76ceab	19,696	215
~/.claude/skills/wake-up/SKILL.md	2341552bd137fa329bbc5ade2908a53f	18,487	161

Per-quote containment — exact byte substring, no normalisation, no fuzzy matching:

Quoted passage	File	Line	Result
§1.6 change-class clause ("Mechanical updates … the same FIX-vs-PROPOSAL split, one level up")	wrap-up	75	contained
§1.6 blanket prohibition ("never create, patch, or retire a skill autonomously at wrap")	wrap-up	80	contained
§1.6 event-based sentence ("This is event-based, not change-count …")	wrap-up	75	contained
§2.a register read ("Read skill-harvest-register.md directly …")	wake-up	63	contained

Controls: positive (a known-present clause is found) pass; negative (an invented clause, "the executor may patch any skill without reporting it", is absent) pass; cross-file negative (the §2.a text does not appear in the wrap-up file, confirming the two sources are distinct and not one file matched twice) pass.

Q1's timeline, affirmed by the jurist as "unverified directly" — now verified directly, from git rather than from a provenance comment:

• The blanket prohibition entered wrap-up/SKILL.md on 2026-05-29 (fffcf17).
• The change-class clause entered on 2026-07-05 (9ca673f) — 37 days later, carrying its own <!-- 2026-07-05: CLAUDE.md-freshness check, steward-authorized --> provenance comment at line 75.

So "the distinction was drawn later and simply not carried back" is a git-verified fact, not a timeline inference. It does not rescue the lean from being the interested party's reading — the jurist's coherent alternative stands or falls on its own — but the factual premise it rested on is now checkable by anyone with the repository.

What proceeds now

1. Steward places REVIEWED-85. Not yet placed; the block is in the ruling file, plain-fenced and paste-ready.
2. Then land the §1.6 edit: two-clause disjunctive test · sharpened floor per correction 2 · all three instruments per correction 1 · provenance comment in /wrap-up SKILL.md · no change to ~/CLAUDE.md. Tag commits REVIEWED-85.
3. Then apply today's four proposals (ledger ## What held section, prevention KG predicate, the wake line, the reframed standing question) as the first FIX-lane batch, each recorded in the new index — the material for the check-in.
4. Then the bounded check-in, at the first batch or one month, whichever comes first.

Nothing at steps 2–4 is done. The landing awaits placement; this Addendum discharges only the verification condition.

A note the executor is deliberately not folding in

A steward–jurist exchange accompanied the ruling (contamination, Anthropic's published position on recursive self-improvement, and "differently biased checkers rather than unbiased ones"). It has been read as background. Per the jurist's own direction it carries no governed weight and is not filed with the ruling: making any of it doctrine would be "its own item: what exactly gets added, where it lives, and why now, ruled on rather than absorbed by inclusion." Recording that here so its absence is a decision rather than an oversight.