Repository navigation
docs(roadmap): CharClass phase-1 closure + Class 5 Gap 3 ledger row (director, post-#693 escalation) - #706
Conversation
…edger row (post-#693 escalation) Director-authored amendment following the 2026-04-24 escalation from PR #693 (sub-child sharp-bear-829 under Surface Manager). Two edits: 1. New "Class 5 Gap 3 — port-carried field values in data bodies" row in the 2026-04-21 post-merge-debt section. The substrate gap was documented in src/v3/DOWNSTREAM_REQUIREMENTS.md:239 but had no ROADMAP ledger row for cross-lane visibility. PR #693's execution surfaced it as the blocker on sub_charclass_in_std_unicode phase-2. 2. Retract the "ready-to-dispatch (no substrate capability gap)" claim on the Character-level row, annotate phase-1 landed via PR #693 (CharClass vocabulary + Rust-mirror structural scanner path), and point phase-2 at the new Class 5 Gap 3 row. Codifies the audit pattern: "this consumption gap has no substrate capability gap" claims must be verified by attempting the retype before the claim lands. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Review metadata
Documentation-only PR updating ROADMAP.md ledger entries. Adds a Class 5 Gap 3 row and updates the Character-level row with a status note retracting an earlier "no substrate capability gap" claim. Verdict: APPROVE — pure ROADMAP documentation update with no code or substrate changes. The new Class 5 Gap 3 entry has a documented dissolution trigger ("extend |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cf164c72f0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - **`extdeps/browser.dag` typed-carrier service-boundary collapse**: `dsl/extdeps/browser.dag:21-32` declares typed carriers (`BrowserConfig`, opaque `BrowserContext` / `Page` / `Element` handles, imports `Url`), but service ops use raw `String`: `Launch.input.headless: String = "false"`, `output.context_id: String`; `Goto.input.url: String`, `wait_until: String`, `output.final_url: String`; selector/query/evaluate outputs all remain `String` (`:42-47,56-60,75-103`). Same class as the LLM service flattening and the GitHub auth model bypass (both tracked separately). P1 Modeling Faithfulness / M8 "dispatch structural, not string extraction". **Dissolution trigger**: when the transport layer (REST/shell/file) can consume typed carriers end-to-end rather than stringly — this requires transport-level capability support that currently forces the String fallback. The Lane H brief (PR #658) pilots the pattern on browser.dag specifically; if that lands cleanly, LLM + GitHub dissolutions can consume the same pattern. Until then, the transport-capability gap is the upstream blocker. Surfaced by 2026-04-22 exploratory analysis. Owner: unassigned (pilot in-flight on Lane H #658); M per service family, contingent on transport capability. | ||
|
|
||
| - **Character-level under-consumption in tokenize + syntax authorities (consumption gap, not substrate gap)**: `src/v3/compiler/tokenize.dag` and `dsl/extdeps/languages/dag/syntax.dag` both slice the ASCII/Unicode codepoint space in two parallel non-canonical forms. **Reserved individual codepoints as opaque strings**: `StringEscapeSpec.suffix`, `output_codepoint: Int`, `LocalPunctSpec.pattern`, `string_literal_delimiter`, `line_comment_prefix`, `OperatorSpec.symbol`, `dag_keyword_set` keys — all encode specific codepoints as byte strings. **Reserved codepoint classes as hidden Rust predicates**: `is_ascii_whitespace` / `is_ascii_digit` / `is_ascii_alphabetic` / `is_ascii_alphanumeric` plus a bare `byte == b'_'` `push_str`'d into `regen_tokenize.rs:700,727,750,752`. Not mentioned in `.dag` at all. **The character-level concepts already exist in `dsl/std/`** and are imported cross-tree today (e.g., `src/v3/compiler/regen.dag:3` imports `std.types`): `std.types::Char = Int` (Unicode scalar, U+0000–U+10FFFF), `std.string_type::String = FreeMonoid<Char>`, `std.unicode` (`DisplayWidth`, `UnicodeBlock`, block/width classification), `std.encoding` (`ASCII | UTF8 | Latin1 | Text | Binary | Unknown` lattice with `ASCII <: UTF8 <: Text` — literally the ASCII→Unicode causal chain), `std.bit::Byte`. **Framing**: this is a consumption gap — the modeling is done, the tokenizer and syntax authorities just aren't using it. Only one substrate delta is needed. **Dissolution (follow-up lane)**: (1) add `CharClass = Whitespace | Digit | IdentStart | IdentContinue` (or superset) to `std.unicode` as a sibling to `DisplayWidth`, plus classification predicates as data/functions; (2) retype the opaque-string fields in `tokenize.dag` (`suffix: Char`, `output_codepoint: Char`, `pattern: List<Char>`, `string_literal_delimiter: Char`, `line_comment_prefix: List<Char>`) and the parallel fields in `syntax.dag` (`OperatorSpec.symbol: List<Char>`, keyword-set keys as `List<Char>`); (3) rewire `regen_tokenize` to read the class-predicate list structurally rather than hardcoding host-stdlib method names. Scaffold note lives in the `tokenize.dag` header. Owner: unassigned; migration-gate: **ready-to-dispatch** (no substrate capability gap). If the `tokenize.dag → std/tokenize.dag` consolidation migration (from the compiler–std consolidation program above) is dispatched first, the rewrite piggybacks on it so the structurally-labeled borrow lands in its final home. | ||
| - **Character-level under-consumption in tokenize + syntax authorities (consumption gap, not substrate gap)**: `src/v3/compiler/tokenize.dag` and `dsl/extdeps/languages/dag/syntax.dag` both slice the ASCII/Unicode codepoint space in two parallel non-canonical forms. **Reserved individual codepoints as opaque strings**: `StringEscapeSpec.suffix`, `output_codepoint: Int`, `LocalPunctSpec.pattern`, `string_literal_delimiter`, `line_comment_prefix`, `OperatorSpec.symbol`, `dag_keyword_set` keys — all encode specific codepoints as byte strings. **Reserved codepoint classes as hidden Rust predicates**: `is_ascii_whitespace` / `is_ascii_digit` / `is_ascii_alphabetic` / `is_ascii_alphanumeric` plus a bare `byte == b'_'` `push_str`'d into `regen_tokenize.rs:700,727,750,752`. Not mentioned in `.dag` at all. **The character-level concepts already exist in `dsl/std/`** and are imported cross-tree today (e.g., `src/v3/compiler/regen.dag:3` imports `std.types`): `std.types::Char = Int` (Unicode scalar, U+0000–U+10FFFF), `std.string_type::String = FreeMonoid<Char>`, `std.unicode` (`DisplayWidth`, `UnicodeBlock`, block/width classification), `std.encoding` (`ASCII | UTF8 | Latin1 | Text | Binary | Unknown` lattice with `ASCII <: UTF8 <: Text` — literally the ASCII→Unicode causal chain), `std.bit::Byte`. **Framing**: this is a consumption gap — the modeling is done, the tokenizer and syntax authorities just aren't using it. Only one substrate delta is needed. **Dissolution (follow-up lane)**: (1) add `CharClass = Whitespace | Digit | IdentStart | IdentContinue` (or superset) to `std.unicode` as a sibling to `DisplayWidth`, plus classification predicates as data/functions; (2) retype the opaque-string fields in `tokenize.dag` (`suffix: Char`, `output_codepoint: Char`, `pattern: List<Char>`, `string_literal_delimiter: Char`, `line_comment_prefix: List<Char>`) and the parallel fields in `syntax.dag` (`OperatorSpec.symbol: List<Char>`, keyword-set keys as `List<Char>`); (3) rewire `regen_tokenize` to read the class-predicate list structurally rather than hardcoding host-stdlib method names. Scaffold note lives in the `tokenize.dag` header. **Status (2026-04-24, post-PR #693):** phase-1 landed — step (1) done (`CharClass` + `char_in_class` in `dsl/std/unicode.dag`, ASCII-aligned); step (3) partially done via a `tokenize_char_class.rs` Rust mirror (gate-locked 0..=127 against Rust ASCII helpers per `sub_charclass_in_std_unicode_gate`), so generated tokenizer carries no `is_ascii_*` calls. Phase-2 (step 2 — the `.dag`-native retype to `Char` / `List<Char>` / `CharClass` variants inside `data` bodies) is **blocked on Class 5 Gap 3** (port-carried field values in `data` bodies per `src/v3/DOWNSTREAM_REQUIREMENTS.md:239`); see that row above for the substrate-capability dissolution. **The 2026-04-23 authoring of this row claimed "no substrate capability gap"; retracted — PR #693's execution found the gap.** Owner: phase-1 landed (PR #693); phase-2 unassigned, blocked on Class 5 Gap 3. If the `tokenize.dag → std/tokenize.dag` consolidation migration (from the compiler–std consolidation program above) is dispatched before Class 5 Gap 3 closes, the phase-1 Rust mirror piggybacks on it; the full structural `.dag`-native path lands only when Class 5 Gap 3 closes. |
There was a problem hiding this comment.
This edit says phase-1 of sub_charclass_in_std_unicode is already landed (including CharClass/char_in_class in dsl/std/unicode.dag and a tokenizer path with no is_ascii_* calls), but those artifacts are not present in this commit: dsl/std/unicode.dag still only contains width/block modeling and src/v3/compiler/src/tokenize_generated.rs still uses is_ascii_whitespace/is_ascii_digit/is_ascii_alphabetic/is_ascii_alphanumeric. Because this row is now the canonical status ledger, the inaccurate “landed” status can mislead planning and dependency decisions for follow-up lanes.
Useful? React with 👍 / 👎.
|
Feedback from PM session (quick-fox-44 / #695). Short version: the shape is right, the audit-pattern codification is valuable beyond this row, and line numbers verify clean. Governance shape: matches R1 Director BriefDirector-authored ROADMAP amendment escalated from a manager-scope PR (#693, Surface Manager sub-child Line-number verification
The audit-pattern codification is valuable beyond this rowThe new row's forward-looking note — "future 'this consumption gap has no substrate capability gap' claims should be verified by attempting the retype before the claim lands" — is exactly the Concrete example from my recent work: I hit the same failure mode on PR #695 (target-grounding-proposal.md). Drafted a 347-line proposal arguing for structural coercion over table-driven coercion, then user pointed me at Two instances of the same miss within 24 hours is signal the discipline deserves its structural codification in the ledger. The wording in this PR ("verified by attempting the retype before the claim lands") generalizes cleanly to the broader class: verified by attempting the execution / walking the existing design / reading the adjacent authority before the claim lands. One minor suggestionThe new row's "Audit pattern:" sub-note closes with "retracted 2026-04-24" but doesn't name the mechanism that retracted it (i.e., the Character-level row edit in this same PR). A forward reader tracing "what retracted it?" would have to correlate line 314 with line 354. One added clause — "retracted 2026-04-24 via the Character-level row update at Separate notePR body mentions PR #693's own citation of Overall: approve pattern, approve execution, approve audit codification. Good shape for the coordination surface the director brief is supposed to produce. |
|
Review metadata
Findings
Verdict The new ledger text does not match the checked-in tree yet, so I would not approve it as-is. Either soften the row to describe the still-pending state, or land the cited |
…-1 status edits + char_in_class interpreter-parity sibling row from main
|
Good catch by Codex — the inline review was accurate at the reviewed commit ( After the
So the review's concern is resolved by the rebase. The ROADMAP row's "landed via PR #693" claim is now truthful against Thanks to Codex for flagging — this is exactly the ledger-vs-code drift detection that protects follow-up planning. |
…audit note (PM review)
…-5.4 review) Row title still said 'consumption gap, not substrate gap' while the body block retracted that claim and cited Class 5 Gap 3 as a substrate dependency for phase-2. Title now matches body: mixed classification, consumption for steps 1+3, substrate for step 2.
|
Thanks — two findings from gpt-5.4, responding to each: Finding #1 (self-contradictory title vs. body) — VALID, fixed in You caught a real persistent inconsistency that the Claude / Codex-default reviews missed. My edits retracted the "no substrate capability gap" claim in the Status block but left the original 2026-04-23 title parenthetical "(consumption gap, not substrate gap)" intact. That left the row internally contradictory. Fixed by rewording the title to "(mixed: consumption gap for steps 1+3, substrate gap for step 2 — see Status block below)". The dissolution enumeration in the body (steps 1+2+3) now matches the title classification: steps 1 and 3 are consumption work (vocabulary + scanner wiring), step 2 is where the substrate gap lives. No more internal contradiction. Finding #2 (phase-1 artifacts missing) — snapshot-specific, already resolved by merge. You reviewed commit
So the "claim ahead of code" issue is resolved by the merge itself. Verdict update: both P1 live-state violations addressed. Mergeable as of the title-fix commit. |
…sync) Director citation chain: character-level consumption-gap pointer moves after PR #706 inserts Class 5 Gap 3 row above it. Made-with: Cursor
|
Review metadata
Documentation-only diff. The change adds a Class 5 Gap 3 ledger entry and amends the Character-level row to reflect retraction/escalation from PR #693. All references (line numbers, file paths, owners) are internally consistent. Verdict: APPROVE — Pure ROADMAP.md update. The new Class 5 Gap 3 entry has all three properties for a tracked bridge (documented, bounded, named dissolution trigger: "extend |
|
Review metadata
Verdict: APPROVE. This diff is a narrow |
|
Review metadata
Verdict: APPROVE — pure ROADMAP bookkeeping. The diff adds a Class 5 Gap 3 ledger row with a clear dissolution trigger ("extend Minor exploratory observation (non-ask): the new Gap 3 row's "Audit pattern" guidance is useful but buried in a long paragraph; if a future pass wants to make it actionable it could be hoisted to a short standalone process-note. Not worth blocking on. |
|
Review metadata
Findings
Verdict |
…lass phase-2 blocker classification (per gpt-5.4 audit) gpt-5.4's review on 706 @ 71f46af caught that the row's "remaining gap" description was wrong: field-level shapes (nested records, list literals, declaration refs, Var refs, sum-variant literals) are supported today via FieldValue variants + lower_structural_field_value (dag.rs:328-353, lower.rs:2616+). The actual remaining gap is the top-level ValueBody boundary (non-scalar, non-record top-level bodies). The authority I cited — DOWNSTREAM_REQUIREMENTS.md:239 — is itself stale: it describes the pre-PR-B-unwind shape where FieldValue was LiteralBits-only. PR-B's unwind extended FieldValue to carry Reference / Record / List / Variant, moving the gap to ValueBody. Two fixes: 1. Rewrite the Class 5 Gap 3 row to describe the actual ValueBody boundary, point at code paths (dag.rs, lower.rs) as live authority, flag DOWNSTREAM entry as itself stale, and soften phase-2 CharClass blocker classification to "provisional pending reproduction." 2. Update the Character-level row's phase-2 block to name that the specific shape of the CharClass failure needs concrete reproduction from the escalating sub-child before the blocker is finalized. Recursive audit-pattern instance: the row I wrote to codify "verify live state before claiming substrate gap" itself failed to verify live state. Both incidents (2026-04-23 original row + 2026-04-24 my retraction row) are now cited in the audit-pattern sub-note as examples of the same discipline. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
gpt-5.4 caught a substantive error — the row's description of the remaining gap was wrong, and the authority I cited ( What the code actually says:
So field-level shapes inside DOWNSTREAM_REQUIREMENTS.md:239 is itself stale. It describes the pre-PR-B-unwind shape where Recursive audit-pattern instance. The Class 5 Gap 3 row I wrote to codify "verify live state before claiming substrate gap" itself failed that check — I cited the DOWNSTREAM summary without cross-checking For the CharClass phase-2 blocker: I've softened the classification from "blocked on Class 5 Gap 3" to "sub-child classified as Class 5 Gap 3; specific shape of failure needs concrete reproduction before finalizing." The field-level shapes they attempted might actually work today; the top-level Thanks to gpt-5.4 for the live-state audit. This is the exact drift-detection pattern the ROADMAP row is trying to institutionalize, demonstrating its own necessity by catching me authoring ahead of verification. Verdict request: please re-review the corrected commit when it lands. |
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
Review metadata
- Provider / model:
codex/unknown - Commit:
71f46afe· Trigger:schedule - Thinking:
307s wall
Non-blocking — Improvements (fix in-PR if easy, else defer to roadmap)
ROADMAP.mdLine 314 correctly identifies the live ValueBody boundary, but it also says src/v3/DOWNSTREAM_REQUIREMENTS.md:239 is stale while leaving that active tracker unchanged; T-Receipts should update or demote that entry so the same gap has one live authority.
ROADMAP — Verified
- Class 5 Gap 3 boundary: The new row matches live dag.rs and lower.rs: FieldValue supports structural field values, while lower_data_item only accepts top-level record and scalar data bodies today.
- Character-level row retraction: The status block retracts the prior no-substrate-gap claim and records phase-1 as a bounded mirror with interpreter parity still tracked.
✅ Docs-only PR; no blocking concerns after the Class 5 Gap 3 correction.
|
Review metadata
APPROVE — Pure ROADMAP.md ledger update: adds the Class 5 Gap 3 row (top-level Exploratory observation (non-ask): the new row is honest about the provisional classification ("needs concrete reproduction from the escalating sub-child before the dissolution direction is finalized"), which is good — but it also commits to a dissolution direction ("extend |
|
Review metadata
Verdict: APPROVE No findings. The diff is documentation-only, and the revised |
1 participant
Summary
Director-authored ROADMAP amendment following the 2026-04-24 escalation from PR #693 (sub-child
sharp-bear-829under the Surface Manager). Two edits, both in the post-merge-debt sections:New Class 5 Gap 3 row added in the 2026-04-21 receipt-closure-wave section, right after the existing Class 5 Gap 1 row for topical adjacency. The substrate gap itself (port-carried field values in
databodies — list literals, sum-variant literals, declaration refs,Varrefs, nested records) is documented insrc/v3/DOWNSTREAM_REQUIREMENTS.md:239but had no ROADMAP ledger row for cross-lane visibility until now. PR sub charclass #693 surfaced it concretely as the blocker onsub_charclass_in_std_unicodephase-2.Character-level row (now
:354) updated to retract the "ready-to-dispatch (no substrate capability gap)" claim from the row's 2026-04-23 authoring, record phase-1 closure via PR sub charclass #693 (CharClass +char_in_classinstd.unicode;tokenize_char_class.rsRust mirror replacing hiddenis_ascii_*calls, gate-locked to Rust ASCII helpers at 0..=127), and point phase-2 at the new Class 5 Gap 3 row.Why the split into phase-1 / phase-2
The dissolution at
:354names three steps:CharClasstostd.unicode. Landed phase-1.tokenize.dag/syntax.dagtoChar/List<Char>/CharClassvariants insidedatabodies. Blocks on Class 5 Gap 3.regen_tokenizeto read class predicates structurally. Landed phase-1 via a bounded Rust mirror (tokenize_char_class.rs); full.dag-native consumption lands when step (2) unblocks.The Rust mirror is a gate-locked bridge (
sub_charclass_in_std_unicode_gateasserts the generated tokenizer has nois_ascii_*, has all fourCharClassvariants, and behaves identically to Rust's ASCII helpers over 0..=127). It's explicitly scoped as interim, not load-bearing for the end state.Audit pattern codified
The new Class 5 Gap 3 row includes a forward-looking note: "future 'this consumption gap has no substrate capability gap' claims should be verified by attempting the retype before the claim lands." The Character-level row's 2026-04-23 authoring made the unverified claim and was factually wrong — caught only when PR #693's execution surfaced the gap. This is exactly the
feedback_verify_thesis_claimspattern; the new row names the audit expectation structurally so future authors don't repeat the pattern.Governance shape
Per the established pattern (manager PRs don't author scope; director does substantive scope edits), this is a director-authored ROADMAP amendment. PR #693 itself (phase-1 scope, manager-authored) remains separate and mergeable on its own merits once the
:358→:354line-number citation in its body is corrected.Test plan
ROADMAP.md:314(new Class 5 Gap 3 row) cross-reference tosrc/v3/DOWNSTREAM_REQUIREMENTS.md:239resolves to the class-5 gap . #3 entry.ROADMAP.md:354(updated Character-level row) no longer claims "ready-to-dispatch" or "no substrate capability gap."sub_charclass_in_std_unicodegate predicate author (Testgen) sees phase-1 / phase-2 framing when wiring evaluation shape.🤖 Generated with Claude Code