Split the RFC 0006 accepted set into focused child RFCs (6.1.1)

[leynos]

Summary

Roadmap task 6.1.1 asks for the accepted capability set in
RFC 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

• Eight child RFCs, 0013 to 0020, one per roadmap phase-6 capability step
  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.
• RFC 0006 section 8 stays intact and normative. Child RFCs are additive,
  matching the convention RFCs 0009 to 0011 already use for RFC 0001. This
  reverses the first draft, which migrated the per-helper contracts out.
• Each child carries a five-column registry naming every helper in its
  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.
• The success criterion becomes executable, derived from RFC 0006's own
  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:

• The word open was doing real work — an issue closes when its capability
  lands, and an RFC never closes. That burn-down is preserved by the roadmap
  checkboxes, which already decompose every capability group into tasks.
• The criterion now reads "exactly one child RFC and by at least one
  accompanying roadmap task". Requiring exactly one task would be false today:
  product is already named by both 6.4.2 and 6.4.5.

A new obligation COV-6 checks the roadmap half 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.

RFC 0006 says "child issue" in seven further places; correcting those is
EP-M1 work 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 note and
Decision log. The findings that changed the design most:

• The first draft's motivating premise was false. The roadmap already carries
  See RFC 0006 §8.N deep links on all 51 phase-6 task and step bullets, so
  reaching the combine contract costs about 80 lines today, not 2132.
• Migrating section 8 would have stranded 39 roadmap task citations on stubs,
  with no link gate in the repository to notice.
• Heading-based coverage parsing is unworkable: basename and dirname have
  no 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.
• The handwritten forbidden list had already omitted sixteen names, including
  is_file, quote and fileglob — evidence for deriving it instead.

Defects found in RFC 0006

Recorded for correction, none of which changes a disposition:

• Section 8.1 says "All six helpers in this group are pure" and specifies five.
• Section 8.6 says every helper in the group is "pure and lexical", but
  expandvars sits in that group and the same section calls it the one
  environment-observing helper in the RFC.
• The number-allocation table still claims no RFC has been merged to main,
  and omits 0007 to 0012.
• Sections 14 and 17 say "child issues" in seven places.

Review focus

1. The partition table, and the two divisions in particular: expandvars
   to RFC 0018 rather than 0017, and the abs test to RFC 0017 rather than
   0018. Both follow the roadmap and are supported by RFC 0006 section 8.7.
2. Decision D3 — additive children rather than migration.
3. Whether eight RFC numbers is proportionate. Numbers cannot be renumbered
   after publication, and this repository has a measured collision base rate of
   three (adr-003, adr-004, adr-014 are all duplicated). The plan
   allocates lazily and offers an EP-M1-only fallback in
   Alternatives considered.

Notes

• Documentation-only apart from one new test binary. No helper, registration,
  locale key, flag, configuration field or dependency changes.
• No disposition is changed and none of RFC 0006's seven open questions is
  resolved; each is carried into its owning child, unresolved.
• make check-fmt, make markdownlint and make nixie pass on this branch;
  make lint, make typecheck and make test passed on the rebased state.
• The plan is explicit that the semantic adequacy of the contract discharges is
  reviewer-checked, not test-checked, and must not be overclaimed.

References

• Roadmap task 6.1.1, docs/roadmap.md
• RFC 0006 originating issue #596 (closed)
• Hardening release issue #594 (closed; v0.1.0 final has not shipped)
• Lody session

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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

[sourcery-ai]

Reviewer's Guide

This 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 ownership

erDiagram
    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
    }

Loading

Flow diagram for the planned RFC coverage validation

flowchart 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

Loading

File-Level Changes

Change	Details	Files
Adds an approval-gated execution plan for splitting RFC 0006’s accepted helper set into eight additive child RFCs aligned with roadmap steps 6.2–6.9.	Defines the 57-helper partition, including the purity-seam assignments for expandvars and abs, and excludes shared machinery and deferred or rejected candidates. Keeps RFC 0006 section 8 normative and specifies child RFCs 0013–0020 as focused conformance records rather than migrated contracts. Introduces five-column per-helper registries covering namespace, registration kind, purity, and manifest-query availability. Plans updates to RFC 0006, the roadmap, and the RFC index, including corrections to documented count, purity, numbering, and child-issue wording defects. Records decision rationale, alternatives, risks, approval gates, rollback strategy, and milestones for auditing, implementation, and reconciliation.	docs/execplans/6-1-1-split-rfc-0006-set-into-focused-child-rfcs-and-task.md
Specifies a mechanically checked documentation coverage invariant without implementing it in this pull request.	Plans a new Rust integration-test binary that derives accepted and forbidden sets from RFC 0006 disposition tables rather than hardcoding inventories. Defines checks for unique ownership, forbidden candidates, namespace and purity totals, coverage-map progress, inter-document links, and child contract-section structure. Documents parser constraints, seeded-fault validation, expected intermediate outputs, and the semantic adequacy gap that remains reviewer-checked.	docs/execplans/6-1-1-split-rfc-0006-set-into-focused-child-rfcs-and-task.md
Captures the review-driven revision from the rejected first draft and establishes explicit approval and scope controls.	Replaces the false navigation-based motivation with missing per-helper contract registries and mechanical bijection checking. Rejects heading-based parsing and handwritten forbidden lists in favour of table-anchored, source-derived validation. Adds an EP-M1-only fallback and a hard go/no-go after the first child RFC to test whether eight numbered RFCs are proportionate. Constrains the work to documentation plus one test binary, with no runtime, dependency, registration, or disposition changes.	docs/execplans/6-1-1-split-rfc-0006-set-into-focused-child-rfcs-and-task.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[codescene-access]

No quality gates enabled for this code.