Conversation
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueComment |
Contributor
Reviewer's GuideThis documentation-only PR adds an approval-gated ExecPlan for partitioning RFC 0006’s accepted capabilities into eight additive child RFCs, with per-helper registries and a source-derived coverage test planned to enforce exact ownership and exclusion of deferred or forbidden candidates. It also records the partition rationale, RFC 0006 corrections, roadmap/index updates, implementation milestones, validation strategy, risks, and a reversible fallback; no implementation or runtime behaviour is included. Entity relationship diagram for RFC capability ownershiperDiagram
RFC_0006_DISPOSITION ||--o{ CHILD_RFC_REGISTRY : derives
CHILD_RFC_REGISTRY }o--|| CHILD_RFC : owned_by
RFC_0006_DISPOSITION {
string helper_name
string disposition
}
CHILD_RFC_REGISTRY {
string helper
string namespace
string registration
string purity_class
string manifest_query
}
CHILD_RFC {
string rfc_number
string roadmap_step
string status
}
Flow diagram for the planned RFC coverage validationflowchart TD
Start[Read RFC 0006 disposition tables]
Accepted[Derive accepted helper set]
Forbidden[Derive deferred and forbidden set]
Map[Read section 14 coverage map]
Registries[Read child RFC section 5.1 registries]
Checks[Run coverage and conformance checks]
Outcome{Partition valid?}
Pass[Proceed with child RFC milestone]
Stop[Stop and escalate]
Start --> Accepted
Start --> Forbidden
Start --> Map
Accepted --> Checks
Forbidden --> Checks
Map --> Checks
Registries --> Checks
Checks --> Outcome
Outcome -->|yes| Pass
Outcome -->|no| Stop
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![codescene-access[bot]](https://avatars.githubusercontent.com/in/3755875?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Adds the execution plan for roadmap task 6.1.1, which splits the accepted capability set in RFC 0006 into nine focused child RFCs aligned one-to-one with roadmap phase-6 steps 6.1 to 6.9. The plan makes the roadmap's success criterion executable: a new contract test asserts that every accepted helper is specified by exactly one RFC, that no deferred or rejected candidate is specified by any, and that the totals agree with RFC 0006 table 11. It also records a deliberate divergence from the tracked roadmap text, which currently says "child issues" where the commissioned task asks for child RFCs and accompanying roadmap tasks. Nothing is implemented; the plan awaits approval. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A six-lens review verified the partition — all 57 helpers, none lost, duplicated, or misassigned — and rejected most of the machinery around it. The plan no longer migrates RFC 0006 section 8 into the children. The repository's convention is additive, migration would strand 39 roadmap citations with no link gate to notice, and two capability groups split across two milestones would leave genuinely incoherent intermediate states. The Purpose section is rewritten because its original premise was false: the roadmap already deep-links every phase-6 task to its RFC 0006 section, so reaching a helper contract costs about 80 lines today. The coverage test is now anchored on tables and derived from RFC 0006's own section 7 rather than on headings and hardcoded constants. Heading anchoring cannot see basename or dirname, miscounts three compound headings, and false-positives on the parent's own sections 10, 11 and 15; the handwritten forbidden list had already omitted sixteen names. Section 5 drops from eleven mandatory prose clauses to five substantive ones with an anti-vacuity rule, a ninth child RFC for step 6.1 is dropped as empty, numbers are allocated lazily against a measured collision rate of three, and a hard go/no-go follows the first completed child. Records two further RFC 0006 defects and corrects several factual errors: issues #596 and #594 are closed, the naive section 8 heading count is 58, and make doc-coverage does not measure integration tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
leynos
force-pushed
the
6-1-1-split-rfc-0006-set-into-focused-child-rfcs-and-task
branch
from
September 8, 2026 15:20
7e3da29 to
578a705
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Rewrites task 6.1.1 from "focused child issues" to "focused child RFCs and accompanying roadmap tasks", and records that delivery is tracked through the roadmap checkboxes in steps 6.2 to 6.9 rather than through separate issues, so progress stays in committed documentation. The success criterion now reads "exactly one child RFC and by at least one accompanying roadmap task". Requiring exactly one task would have been false on the existing roadmap: `product` is already named by both 6.4.2 and 6.4.5, so only the RFC count is exactly one. The execplan's Scope divergence section is retired for Scope: settled, which keeps the reasoning on the record without presenting it as an open question, and D8 is updated. The burn-down that the old word "open" provided is preserved by the roadmap checkboxes rather than lost. Adds obligation COV-6, which checks the roadmap half of the criterion mechanically: every accepted helper must be named by at least one task under the step owning its child RFC. Verified before writing it that all 60 helpers already are, so COV-6 is green on the current roadmap. RFC 0006's seven "child issue" phrases remain EP-M1 work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
leynos
changed the title
`EP-M0` re-derived every count in the plan mechanically from RFC 0006's own section 7 tables. Every derived quantity agrees with the plan except one: the forbidden set is not 34 names under any derivation. 34 reconciles only as a *row* count (50 reject rows less the 22 classed "already provides", plus 6 deferred rows); a name count gives 44 or 46, and the plan's own "exactly 34 members" assertion is mutually inconsistent with its `is_file` membership claim. That inconsistency, not the number, is what made the class-based method untenable. The reviewer resolved the stop condition by choosing `D10`: the deny set is the complement of the accepted set — every surveyed reject or defer name that is not an accepted Netsuke name — giving 71 names. This needs no parsing of RFC 0006's note column and no normative edit to the survey. Table 11's 22/10/18 class split stays derived and is asserted as a separate witness, so `D5` rule 3 remains exercised. Also corrects three smaller defects found while auditing: `D5` rule 2 claimed all three rename rows are rejected when `hash`'s row reads "Accept as `text_hash`"; `COV-3`'s purity aggregate is now scoped to `New` rows, since the three optioned rows include the filesystem-observing `glob`; and `COV-2` is restated in complement form with its non-vacuity assertions. The seven section 16 open questions, the dispositions, and section 8's per-helper contracts are untouched, per the plan's constraints. Co-Authored-By: Claude Code <noreply@anthropic.com>
`EP-M0` recorded a rule that was believed to reproduce table 11's 22 already-provides / 10 redundant-alias / 18 on-principle split over the 50 reject rows: alias if the resolution cell contains "alias" or cites section 10.2, else exists if it begins "Exists" or names a provider in backticks, else principle. Re-deriving it before writing the parser gives 8 alias / 24 exists / 18 principle. The principle third is right, and the premise that every principle row is backtick-free holds. The error is the 32-row remainder, which splits 8/24 against the table's 10/22. The difference is exactly the two rename rows `win_splitdrive` and `fileglob`, which section 7.8 says are "registered under a Netsuke name rather than the surveyed one" and which table 11 therefore counts as aliases while the rule counts them as exists. Recovering 22/10/18 needs those two special-cased out of *exists* while `now` -- also a reject row naming an existing helper in backticked call form -- stays inside it, with nothing in the document to distinguish them. RFC 0006 states no rule assigning a reject row to a class, and section 10 groups only some of them. So the split is not derivable and is no longer asserted anywhere. `COV-2` now asserts the directly parseable totals (55 accept rows, 6 defer rows, 50 reject rows, 111 entries) plus that table 11's three class counts sum to the derived reject-row count -- a real consistency check on the table without claiming a derivation that does not exist. Amended in place: `D10`'s tail, `COV-2`'s closing note, the audit table's last row, the `Surprises` bullet that recorded the rule as working, and the closing narrative. Adding a discriminating column to section 7 remains the remedy if the split is ever wanted as a contract. Co-Authored-By: Claude Code <noreply@anthropic.com>
Adds tests/rfc_stdlib_coverage_tests.rs and its twelve supporting modules: seven checks, one per obligation COV-1 to COV-6 plus CONF-1, each derived from RFC 0006 section 7, section 14.13's coverage map, the child registries, the roadmap, and the link graph. Three checks are vacuously green until a child RFC exists; their non-vacuity comes from seeded-fault controls recorded in the ExecPlan, and a COV-4 control that deletes the map table shows the parser fails rather than reporting a vacuous zero. Lands ADR-021 for the child-RFC convention, adds RFC 0006 section 14.13's coverage map as its table 16, corrects two section 8 group preambles, and repoints roadmap 6.1.1 at the child RFCs. The coverage map's caption was first written as table 12, which collides with the existing table 12; nothing parses captions, so only review caught it. Regenerates typos.toml from the refreshed shared dictionary. The branch predates typos-config-builder, so the committed file carries the two hand-written exceptions main has since replaced with generated ones; the regeneration is what makes spelling-config's `git diff --exit-code` step pass. The branch is 29 ahead and 5 behind main; a rebase will take main's version of both typos files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ten findings from the first review pass on the EP-M1 commit, two of them
duplicates and two competing remediations of the same location.
The substantive one is the clause-discharge heading. It was specified as
`### 5.6. Clause discharge`, which collides with the template's own 5.6,
"Type and error contract" -- the same title RFC 0006 clause 6.6 carries. A
table row reading `6.6` under a heading reading "Type and error contract"
implies the two are the same thing. The subsection loses its number rather
than gaining a rival: it is now unnumbered `### Clause discharge`, closing
section 5 after the eleven clause subsections it resolves. `TABLE_HEADING`
and a match on the heading directly above the table replace the
`starts_with("5.6.")` scan, so a table under one of the clause subsections
cannot be mistaken for the discharge table.
The rest:
- `Section::whole` drops its unused `file` argument; every caller holds the
`&str` it read the text from and takes diagnostics from that.
- `registries::parse_all` takes the numbers the coverage map reserves rather
than matching every RFC file numbered 0013 or later. The corpus is
open-ended, and the map is where the reservation is recorded.
- `links::resolve` returns `Option<String>`, reporting a traversal that
climbs above the repository root instead of dropping the surplus `..`
segments and returning a path that looks ordinary.
- `checks.rs` imports `Context`, so the COV-4 child-link resolution compiles
and reports the root-escaping link rather than panicking on it.
- `section_ref` trims trailing dots: a sentence-final `§8.9.` would otherwise
parse as section `8.9.`, a section that does not exist.
- `roadmap::step_of` is extracted from `parse`, keeping the range latch,
the phase-6 numbering check, and the bullet handling apart.
- ADR-021's `## Decision Drivers` becomes `## Decision drivers`, matching the
three other ADRs that have the heading.
The template in the execplan gains the discharge table's exact placement, so
the eight child RFCs are not written against an ambiguity, and the clause
discharge notes in the plan record the amendment.
Gates: focused coverage suite 7/7; clippy clean on the target.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Four review findings, two of them latent defects rather than style. The parser was fence-blind. A fenced `#` line read as a heading, which ended the enclosing subsection and dropped every helper specified below it: seeding one into RFC 0006 section 8.9 failed six of the seven checks and blamed two helpers rather than the code block. Every child RFC this plan writes carries example fences in section 5, so the fault was one document edit from being live. Three scans shared the root cause and now consult one `Fences` cursor, extracted with the rest of the Markdown lexical layer into `markdown.rs`; the module split also keeps every module under Whitaker's 400-line cap. The purity aggregate did not apply the `New`-row scoping its own comment described. Section 6.1's 52/4/1 counts the 57 proposed helpers, while the registries carry all 60 accepted ones, so filtering on purity alone yields 54/5/1 and would have failed a correct document at EP-M11. The filter now lives in `new_with_purity` rather than at the call site. The remaining two: `clauses.rs` quoted RFC 0006 section 6 with the obsolete `child issue` term, and RFC 0006 table 1 recorded the RFC's `Status` in a column whose every other row records a merge state. The merge claim was accurate — the row now states the merge like its neighbours, with a sentence under the table separating the two facts. Whitaker's `conditional_max_n_branches` then rejected the fence guard at three branches, where Clippy had passed it. The guard's conditions became two named predicates rather than being flattened, so the "closing fence carries no info string" rule survives; eleven scratch probes over the CommonMark cases confirm it. Both documents were re-canonicalised with a scoped mdtablefix, since `make fmt` cannot be pointed at one file. The fence control's before/after transcripts and all four findings are recorded in the ExecPlan, which also now lists six controls rather than five. Co-Authored-By: Claude Code <noreply@anthropic.com>
leynos
force-pushed
the
6-1-1-split-rfc-0006-set-into-focused-child-rfcs-and-task
branch
from
September 19, 2026 10:18
0549571 to
33baf1a
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Three lint-clippy errors in the extracted Markdown lexical layer, and two contradictions between the plan's child-RFC skeleton and the parser EP-M1 shipped. markdown.rs: backtick `CommonMark` at the two sites clippy names, and make `is_closing_run` a `const fn`. The second cascaded — a `const` callee makes its caller eligible in the same run — so `Delimiter::closes` needed it too. The cascade stops at `mark`, which takes `&mut self` and calls the non-const `Delimiter::opening`. Confirmed with a targeted clippy on the single test target rather than a second full gate cycle. The skeleton EP-M2 is told to "copy literally" failed the parser in two independent places, both of them hard failures on the first row read: - the registry heading read `### 5.1. Purity and manifest-query registry` where `REGISTRY_HEADING` matches `### 5.1. Registry`; and - the manifest-query cell vocabulary was `Available`/`Stub` where `check_manifest_query` accepts `yes`/`no`. Neither was caught at EP-M1 because no child RFC exists yet, so every check that reads a registry is vacuously green — the template was prose the parser had never been pointed at, and the first failure would have landed at EP-M3, after the go/no-go had been spent on a document written to the wrong contract. The template gave way in both cases because the parser already agrees with the parent document: RFC 0006 table 2's own column is headed "Available in manifest queries" with cells `Yes`/`No`, and `### 5.1. Registry` matches section 14.13's "carries the group's registry". Each site now carries a note naming the constant that reads it. Co-Authored-By: Claude Code <noreply@anthropic.com>
There was a problem hiding this comment.
Gates Failed
(4 files with String Heavy Function Arguments)
Our agent can fix these. Install it.
Gates Passed
Reason for failure
| Enforce advisory code health rules | Violations | Code Health Impact | |
|---|---|---|---|
| mod.rs | 1 advisory rule | 9.69 | Suppress |
| registries.rs | 1 advisory rule | 9.69 | Suppress |
| section7.rs | 1 advisory rule | 9.69 | Suppress |
| markdown.rs | 1 advisory rule | 9.69 | Suppress |
Quality Gate Profile: Pay Down Tech Debt
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.
leynos
pushed a commit
that referenced
this pull request
Sep 19, 2026
RFC 0013 to 0020 are reserved by the 6.1.1 child-RFC split plan (PR #697) for the Ansible stdlib filter RFCs, which puts this set in collision at 0013 to 0017. Nothing above RFC 0012 is merged, and the style guide forbids renumbering after publication, so resolve the overlap now by moving this set above #697's ceiling. Rename the five files and update every reference in the two documents that cite them. The change is a pure number substitution: each file is byte-identical to its predecessor once the digits are normalised back. Gates: make fmt (no-op), check-fmt, markdownlint and nixie all pass. Co-Authored-By: Claude Code <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Roadmap task
6.1.1asks for the accepted capability set inRFC 0006
to be split into focused child RFCs and accompanying roadmap tasks, so that
every accepted capability is covered by exactly one RFC and every deferred or
rejected candidate by none.
This pull request adds the ExecPlan, and amends roadmap task 6.1.1 to the
wording the plan implements. No child RFC is written; the plan is
approval-gated.
Plan:
docs/execplans/6-1-1-split-rfc-0006-set-into-focused-child-rfcs-and-task.md
What the plan proposes
6.2 to 6.9. The roadmap already partitions RFC 0006 sections 8.1 to 8.10
completely and disjointly, and it cuts on the purity seam where section
14's delivery slices do not: slice 5 bundles pure lexical path helpers with
filesystem-observing predicates, while the roadmap keeps them apart. Step 6.1
gets no child RFC — it owns shared machinery, not a capability.
matching the convention RFCs 0009 to 0011 already use for RFC 0001. This
reverses the first draft, which migrated the per-helper contracts out.
group with namespace, registration kind, purity class and manifest-query
availability, plus a discharge of the cross-cutting contract for its own
helpers. Section 6.1 requires a purity label per helper and gives only an
aggregate; no such table exists anywhere in the repository today. That is
the substantive product of this task.
section 7 disposition tables rather than hardcoded, so the forbidden set
tightens automatically when section 7 gains a row.
Roadmap task 6.1.1, amended
The tracked task said "focused child issues", with success measured as
"exactly one open child issue". It now says child RFCs and accompanying
roadmap tasks, and records that delivery is tracked through the roadmap
checkboxes in steps 6.2 to 6.9 rather than through separate issues, so progress
stays in committed documentation.
Two consequences worth a reviewer's attention:
lands, and an RFC never closes. That burn-down is preserved by the roadmap
checkboxes, which already decompose every capability group into tasks.
accompanying roadmap task". Requiring exactly one task would be false today:
productis already named by both 6.4.2 and 6.4.5.A new obligation
COV-6checks the roadmap half mechanically — every acceptedhelper must be named by at least one task under the step owning its child RFC.
Verified before writing it that all 60 helpers already are.
RFC 0006 says "child issue" in seven further places; correcting those is
EP-M1work rather than part of this pull request.Design review
A six-lens expert panel reviewed the first draft. It verified the partition —
all 57 helpers, none lost, duplicated or misassigned — and rejected most of the
machinery around it. The revision is recorded in the plan's
Revision noteandDecision log. The findings that changed the design most:See RFC 0006 §8.Ndeep links on all 51 phase-6 task and step bullets, soreaching the
combinecontract costs about 80 lines today, not 2132.with no link gate in the repository to notice.
basenameanddirnamehaveno heading at all, three headings name two helpers each, three are prose, and
RFC 0006's own sections 10, 11 and 15 carry backticked helper names in
non-normative headings.
is_file,quoteandfileglob— evidence for deriving it instead.Defects found in RFC 0006
Recorded for correction, none of which changes a disposition:
expandvarssits in that group and the same section calls it the oneenvironment-observing helper in the RFC.
main,and omits 0007 to 0012.
Review focus
expandvarsto RFC 0018 rather than 0017, and the
abstest to RFC 0017 rather than0018. Both follow the roadmap and are supported by RFC 0006 section 8.7.
D3— additive children rather than migration.after publication, and this repository has a measured collision base rate of
three (
adr-003,adr-004,adr-014are all duplicated). The planallocates lazily and offers an
EP-M1-only fallback inAlternatives considered.Notes
locale key, flag, configuration field or dependency changes.
resolved; each is carried into its owning child, unresolved.
make check-fmt,make markdownlintandmake nixiepass on this branch;make lint,make typecheckandmake testpassed on the rebased state.reviewer-checked, not test-checked, and must not be overclaimed.
References
6.1.1,docs/roadmap.mdv0.1.0final has not shipped)🤖 Generated with Claude Code