Repository navigation
Fix Value serialization and implement is_empty() method - #28
Merged
Merged
Conversation
…ware NonEmpty Add Value::is_empty() to core/ir as centralized emptiness semantics. Fix value_to_rust_literal: recursive List serialization (was filter_map dropping non-strings), Map support, panic on unserializable variants instead of silent <MOCK> degradation. Fix NonEmpty codegen to use is_empty() instead of string-only as_str() check. Fix value_to_code in mock_spec.rs with same coverage. Regenerate all test files. Closes hacks 3, 4 from TODO_hacks.md. Closes Value::is_empty() from TODO_type_system.md. https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
Key additions from the stuck agent's conversation: - Pipeline cliff visualization (structured data → format!() strings) - Two-layer design: ValueExpr (data) separate from CodeOp (control) - Cross-language semantics table for operations that differ per backend - Language stubs (Python/TS) at Phase 0, not Phase 4, to validate the abstraction upfront - Call out value_to_rust_literal/value_to_code duplication as symptom - Frame as "minimal cross-language expression language" not just refactor - Request/Response must be explicitly modeled, not silently degraded https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
Pin down the proto-like minimal type language: what's in scope (bool, i64, string, json, list, map, struct, unit) and what's explicitly out (unsigned, pointers, enums, generics) with rationale. Add cardinality interval table showing how [0,1]/[1,∞)/etc map to per-language idioms (Option, Vec, Optional, list). This captures the conversation intent that cardinality is port metadata driving backend type selection, not a type called "List". https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
- ValueExpr in core/ir: total Value → ValueExpr conversion covering all 11 Value variants including Request/Response → Struct. No catch-all. Compiler-enforced exhaustiveness. - Test IR in core/codegen: TestFile, TestFn, Stmt, Expr, Assert types capturing test semantics without encoding target-language syntax. - TestRenderer trait: render_value, render_expr, render_stmt, render_assert, render_import, render_file. - RustRenderer: full implementation with 7 passing tests. - PythonRenderer + TypeScriptRenderer: stubs that compile (validating the trait surface) but todo!() at runtime. Phase 0 design validation. https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
Replace format!() string interpolation in codegen.rs with structured test IR rendering: - value_to_rust_literal: one-liner via RustRenderer.render_value() - cardinality_case_mock_value: builds ValueExpr, renders via RustRenderer - default_mock_for_type: models TransportResponse::Shell as ValueExpr::Struct - render_output_matcher_check: new function replacing to_check_code() call, builds Assert IR and renders via RustRenderer Cosmetic changes in regenerated tests (semantically identical): - Empty strings: String::new() → "".to_string() - String lists: Value::str_list() → Value::List(vec![Value::Str(...)]) All 48 codegen tests + full test suite pass. https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
… resource type lists
- Delete dead code in mock_spec.rs: to_check_code(), value_to_code(), and
test_output_matcher_to_check_code (superseded by render_output_matcher_check)
- Extract is_resource_type()/is_resource_port() helpers in obligation.rs,
replacing 4 copy-pasted blocks of ToolHandle/Lock/Lease/SharedLock checks
- Extract escape_rust_str() in render_rust.rs, replacing 10 inline
.replace('\\', "\\\\").replace('"', "\\\"") calls
- Unify render_value/render_struct_field_value into single render_value_inner
with ValueMode::Wrapped/Bare, eliminating ~50 lines of duplicated match arms
- Consolidate render_rust_struct's double-parse of transport variant names
into a single if-let chain returning (wrapper, enum_path, struct_type)
Net: -54 lines, 0 generated test changes, all 49 codegen + full suite pass.
https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
- Resolve merge conflict in TODO_type_system.md: take main's restructured task list, add Value::is_empty() to completed, mark codegen item 3 as in progress - Handle Value::Set in value_expr.rs (maps to ValueExpr::List) and is_empty() (delegates to inner vec) - Update TODO_hacks.md: mark Hack 2 Request/Response serialization as done (via ValueExpr pipeline), update Notes to reflect root cause fixed https://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq
Merged
This was referenced May 7, 2026
briansrls
added a commit
that referenced
this pull request
May 9, 2026
6 tasks
briansrls
added a commit
that referenced
this pull request
May 9, 2026
briansrls
added a commit
that referenced
this pull request
May 9, 2026
2 tasks done
briansrls
added a commit
that referenced
this pull request
May 9, 2026
Per codex api-review on PR #2427 sha e93ae9f: the §1.8 row #29 promotion to PASSING was not mirrored in §1.7's "Concrete exceptions at HEAD" list (which previously enumerated #97 + #28). Add #29 with the same ratchet-citation shape as the existing entries to keep §1.7 consistent with the §1.8 ledger. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
briansrls
added a commit
that referenced
this pull request
May 9, 2026
) * docs(r3): §1.8 row #29 anthropic_wire_typed_serde_alignment CONSUMER_LANDED → PASSING Cluster I (T-Anthropic-Wire) close-shape per cluster-analysis audit §2 row I = "demo PR + ledger refresh". Refresh DECLARED→CONSUMER_LANDED landed via PR #2399 (10-row sweep). This commit promotes #29 to PASSING with named receipts: - `anthropic_request_coproduct_wire_contracts_emit_targeted_serde` (src/v2/tests/src/pipeline.rs:6482) — emit-side wire-tag ratchet - `anthropic_messages_request_body_json_matches_messages_wire_tags` (src/v2/tests/src/pipeline.rs:6918) — round-trip JSON equality Both green at HEAD 9d9f7d7 (verified via `cargo test -p v2-compiler-tests anthropic_ -- --skip should_fail`; 7/8 anthropic_ tests pass; the 1 fail is `anthropic_messages_uses_typed_200_body_projection`, which belongs to the separate 200-body coproduct slice 3 work tracked by `structural_coverage_gap_anthropic_messages_200_residual` — NOT in gate #29 scope per ROADMAP §"LLM service flattening" closure-trigger identifier `rest_request_wire_serde_alignment` taxonomy). Doc-only ledger receipt; no code changes. Mirrors gate #17 PR #2409 + gate #23 PR #2418 close-shape. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §1.7 — add #29 to concrete-exceptions list (codex review fix) Per codex api-review on PR #2427 sha e93ae9f: the §1.8 row #29 promotion to PASSING was not mirrored in §1.7's "Concrete exceptions at HEAD" list (which previously enumerated #97 + #28). Add #29 with the same ratchet-citation shape as the existing entries to keep §1.7 consistent with the §1.8 ledger. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
briansrls
added a commit
that referenced
this pull request
May 9, 2026
Extend omni_layers_share_one_node_tree to call emit_rust on the same Dag as route/OpenAPI/Markdown projections (fixture gains a minimal top-level Int bind so emit_rust is defined). Update §1.8 Notes + thesis mapping to list Shape A Rust emission alongside the interim route projection and Shape B artifacts. Addresses codex BLOCKING on gate #28 PASSING vs r3-structure acceptance. Co-authored-by: Cursor <cursoragent@cursor.com>
This was referenced May 9, 2026
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…emission story) per operator follow-up 2026-05-13 Operator framing 2026-05-13: "regarding bugs - what are some of the other bugs that traditional compilers would have no chance of finding - i'm thinking of subtle bugs between disparate modules" + "yes please - its the class of bug i'm most interested in personally - and i think its a good story regarding omni emission i.e. seeing bugs between javascript and rust or something" New §2.5.E with 3 enumeration tiers: **Cross-module bug shapes** (within same emission target): - Cross-module effect-leak through "pure" boundary (R3 anchor: #82) - Cross-module cost-composition emergence (R3 anchor: #70 + #105) - Cross-module dimensional drift / unit confusion (Time<MS> vs Time<NS>) - Cross-module ordering / sequencing assumption - Cross-module callback effect-set drift - Cross-module aliasing / shadow definition (INVARIANTS P1) - Cross-module data-flow capability leak (Secret<String>) **Cross-emission-target bug shapes** (Rust ↔ JavaScript ↔ Python via shared .dag substrate): - Cross-target serialization round-trip (field-rename propagation) - Cross-target numeric width (Rust u32 vs JS number 53-bit safe-int; R3 anchor: #18 numeric_width + Q-MachineConstraint-Carrier) - Cross-target effect divergence (async semantics: tokio/Promise/asyncio) - Cross-target boundary trust (Rust ↔ JS via FFI/WASM/HTTP) - Cross-target test-claim transferability (R3 anchor: gate #15 l5_cross_target_consistency) **Falsification probes**: - Run same fixture through 3 R3 targets; do outputs agree? - Cross-language wire scenario (Rust client + JS server from same .dag); verify field-rename / type-marshaling / async-cancellation - Modeling-level cross-target gap (target-specific bug classes without substrate representation; "model the missing dimension" vs "target-specific gap in extdeps lane") Plus PM-derived "cross-module / cross-target story" pitch shape: - Traditional compilers have ZERO visibility (modules linked via symbol tables; emission targets are independent compilers; wire schemas are external authority files) - gunbc: substrate-shared / emission-as-projection — module boundaries are naming partitions not semantic firewalls; emission targets are projections of same Node tree; cross-target structural facts flow forward; wire schemas derived FROM substrate R3 close audit recommendation: demonstrate ONE end-to-end cross- target scenario (e.g., Rust server + JS client from same .dag with field-rename propagation + L5 stdout-parity). Closest existing anchor: gate #28 omni_layers_share_one_node_tree + #15 l5_cross_ target_consistency. Cross-language wire demo would cash the story viscerally. — sent from deep-wolf-155
briansrls
added a commit
that referenced
this pull request
May 13, 2026
… per operator directive (#2839) * docs(r3): §2.5 — Impossible bugs by construction (META-promise) interrogation per operator directive 2026-05-13 Operator asked: "regarding the interrogation questions - i have a lot of questions on impossible bugs - what does it mean that bugs in this language are impossible - by construction? how can you avoid glue bugs? what about user error - what about, emergent behavior you didn't intend for?" This is a META-promise that ties §1 (dimension promises) + §2.1-§2.4 (substrate promises) together. The claim is sharp on some classes and softer on others; interrogation needed for honest R3 close. New §2.5 section with 4 probe sub-areas matching operator's asks: - **§2.5.A "What 'impossible' actually means"** — probes the definitional meaning. Discriminates "(a) impossible to express in surface vocabulary" from "(b) caught at compile time by lens"; asks about compiler-correctness gating; falsification via historical "impossible" bug instances. - **§2.5.B Glue bugs** — 5 glue layers enumerated (substrate→emit target, emitter→runtime, lens composition, bootstrap, ExecuteCommand PB-Runtime boundary). Each probed for structural enforcement vs. convention/comment/runtime-assertion. Falsification: identify glue boundaries with NO structural enforcement at HEAD. - **§2.5.C User error** — intent vs. spec divergence; wrong-contract acceptance; empty-program semantics; spec-as-program collapse implication. Falsification: enumerate 3 user-error classes the architecture can NEVER catch by construction. - **§2.5.D Emergent behavior** — lens-composition / scale-only / time-evolving / lens-set silent-gap probes. Falsification: construct a `.dag` program where 4 lens claims pass + program is observably wrong; ask whether response is "model the missing dimension" or "user error is out-of-scope". Plus PM-derived "architectural honest answer" naming SHARP vs. LESS-SHARP claim domains, and recommended R3 close framing: - Closed-set bug-class impossibility (modeled set enumerated) - Reduction-to-glue-boundary (glue probes defined) - User-intent out-of-scope acknowledged - Emergent-behavior probes as PM-curated R3-close evidence - Anti-pattern: "all lenses green = bug-free" is silent universal claim — sent from deep-wolf-155 * docs(r3): §2.5 META — fix INVARIANTS P-citation (P5 → P4 Decidability) per cursor APPROVE_WITH_COMMENTS on PR #2839 cursor flagged that the §2.5 META Promise line cited "INVARIANTS P5 atomic-migration" as authority for "impossible by construction", but: - INVARIANTS P5 is titled "Progress Is Dissolution" (scaffolds, bridges, dissolution progress) — NOT the natural home-of-record for the closed-system / impossible-bug-class thesis claim. - INVARIANTS P4 is "Decidability": "Every accepted program stays within a closed, fail-closed system whose correctness questions are structurally decidable." THIS is the natural structural anchor for the impossible-by-construction META-claim. Verified by reading INVARIANTS.md:247-261 — P4 explicitly carries the closed-fail-closed-decidable semantic commitment that makes bug-class-impossibility a structural property rather than a case-by-case enforcement. Fixed Promise line: - Removed: "INVARIANTS P5 atomic-migration" - Added: "INVARIANTS P4 Decidability" with verbatim cite + P3 Fail-Closed as supporting authority - Added explicit anchor sentence: "The structural anchor is P4 Decidability: closed-system + structurally-decidable-correctness- questions are precisely what makes the bug-class-impossibility claim cash structurally rather than rest on case-by-case enforcement." cursor verdict was APPROVE_WITH_COMMENTS — finding was authority- citation precision, not content rejection. The content of §2.5 (4 probe sub-areas + architectural honest answer + recommended R3 close framing) is unchanged + cursor-approved. — sent from deep-wolf-155 * docs(r3): §2.5.A — defer impossible-bug class enumeration to THESIS authority (operator BLOCKING on PR #2839:154) Operator briansrls flagged at `docs/r3-close-interrogation.md:154` that the §2.5.A probe hard-coded "5" candidate impossible-bug classes (annotation-rot / escape-hatch-leak / complexity-contract-violation / effect-leak-across-pure-boundary / second-source-of-truth) that DO NOT MATCH THESIS.md's Enumerable impossible-bug classes or ROADMAP T-Demo's R1/R2+ split — so the close audit could verify the wrong promise set. Canonical authority verified at HEAD: - **THESIS.md:370-413** "Enumerable impossible-bug classes": - **[R1]** Suboptimal-complexity contract violation - **[R1]** Idempotency-contract violation - **[R1]** Transport/type drift - **[R2+]** Nested-optional flatten - **[R2+]** Unenumerated effects (Tier 1 impossible-by-construction per §Q5.5 OperationEffect-taxonomy retirement) - **[R2+]** Unhandled diagnostic paths - **ROADMAP.md:35** "Impossible-bugs demo suite. Enumerated bug classes with compile-time proofs (see THESIS Enumerable impossible-bug classes). Lane T-Demo." - **ROADMAP.md:93** T-Demo R1 scope: `impossible_bug_class_suite_r1` — idempotency-violation (compose_effects + breaking AppendEffect under IsIdempotent → ResolveError) + transport/type-drift (TypeMismatch). Remaining three are tagged [R2+]. Fix replaces hard-coded "5 candidates" with deferral to THESIS authority + R1/R2+ split per ROADMAP T-Demo. Includes explicit audit discipline: - For [R1] classes: cite substrate fact + demo fixture per ROADMAP T-Demo - For [R2+] classes: confirm R4-DEFERRED disposition with operator- recorded acceptance per §0 vocabulary - Anti-pattern called out: hard-coding a candidate list at audit- author time rather than deferring to THESIS authority is a `feedback_thesis_gate_state_drift`-class miss cursor APPROVE_WITH_COMMENTS verdict from prior review unaffected (content of §2.5.A is improved, not contradicted). — sent from deep-wolf-155 * docs(r3): §2.5.E — cross-module + cross-target subtle bugs (the omni-emission story) per operator follow-up 2026-05-13 Operator framing 2026-05-13: "regarding bugs - what are some of the other bugs that traditional compilers would have no chance of finding - i'm thinking of subtle bugs between disparate modules" + "yes please - its the class of bug i'm most interested in personally - and i think its a good story regarding omni emission i.e. seeing bugs between javascript and rust or something" New §2.5.E with 3 enumeration tiers: **Cross-module bug shapes** (within same emission target): - Cross-module effect-leak through "pure" boundary (R3 anchor: #82) - Cross-module cost-composition emergence (R3 anchor: #70 + #105) - Cross-module dimensional drift / unit confusion (Time<MS> vs Time<NS>) - Cross-module ordering / sequencing assumption - Cross-module callback effect-set drift - Cross-module aliasing / shadow definition (INVARIANTS P1) - Cross-module data-flow capability leak (Secret<String>) **Cross-emission-target bug shapes** (Rust ↔ JavaScript ↔ Python via shared .dag substrate): - Cross-target serialization round-trip (field-rename propagation) - Cross-target numeric width (Rust u32 vs JS number 53-bit safe-int; R3 anchor: #18 numeric_width + Q-MachineConstraint-Carrier) - Cross-target effect divergence (async semantics: tokio/Promise/asyncio) - Cross-target boundary trust (Rust ↔ JS via FFI/WASM/HTTP) - Cross-target test-claim transferability (R3 anchor: gate #15 l5_cross_target_consistency) **Falsification probes**: - Run same fixture through 3 R3 targets; do outputs agree? - Cross-language wire scenario (Rust client + JS server from same .dag); verify field-rename / type-marshaling / async-cancellation - Modeling-level cross-target gap (target-specific bug classes without substrate representation; "model the missing dimension" vs "target-specific gap in extdeps lane") Plus PM-derived "cross-module / cross-target story" pitch shape: - Traditional compilers have ZERO visibility (modules linked via symbol tables; emission targets are independent compilers; wire schemas are external authority files) - gunbc: substrate-shared / emission-as-projection — module boundaries are naming partitions not semantic firewalls; emission targets are projections of same Node tree; cross-target structural facts flow forward; wire schemas derived FROM substrate R3 close audit recommendation: demonstrate ONE end-to-end cross- target scenario (e.g., Rust server + JS client from same .dag with field-rename propagation + L5 stdout-parity). Closest existing anchor: gate #28 omni_layers_share_one_node_tree + #15 l5_cross_ target_consistency. Cross-language wire demo would cash the story viscerally. — sent from deep-wolf-155
2 tasks
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…tor msg_428b032e pre-stage disposition) Per Director msg_428b032e pre-stage disposition on operator directive 2026-05-13 (full-stack-from-one-.dag program + path (a)+(b) ratified): stub adds §3.4 as pointer-only forward-pointer; substantive Q-dispositions land post-canvas-ratification. Structural cash cited (Director-verified 2026-05-13 §1.8 audit): - Gates #25/#26/#27/#28 all CONSUMER_LANDED + PASSING - Path (a) Director-direct demo work-item adhoc-e9bb6ef1-b4d - Path (b) Substrate-Mgr R4 canvas at docs/design-r4-full-stack-omni-emission-canvas.md Stub framing per Director guidance: "no Q-claims; current entry is forward-pointer for thesis-coherence visibility per operator directive 2026-05-13". Probes are deferred placeholders (clearly labeled); substantive answers land when path (a) demo PR + path (b) canvas PR surface. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
5 tasks
briansrls
added a commit
that referenced
this pull request
May 13, 2026
Director RATIFIED all 6 dispositions on PR #2847 R4 canvas (msg_7d51b699 via PM msg_1faad154 2026-05-13): - Q1 RATIFY Q1-b: TypingDiscipline = Nominal | Structural on InhabitantDecl - Q2 RATIFY Q2-a: Shape-A — components ARE TS source code (Rust/Axum etc. symmetric precedent) - Q3 RATIFY Q3-a: .dag → JSX single-authority - Q4 RATIFY EXTEND gate #28 (NOT new parallel gate; gate name is layer-count-agnostic — parallel gate = INVARIANTS P1 violation) - Q5 RATIFY Q5-a: Component is Behavior::Bind - Practice 4 HookKind RATIFY 🟡 YELLOW with R4-Phase-1.5 Practice-4- promotion canvas requirement (Mgr authors before Phase-2 dispatch) Director-added anti-patterns §11 #7-#9: - #7: Adding TypingDiscipline arms beyond Nominal | Structural without ratified consumer evidence - #8: Custom HookKind in R4-Phase-2 without Practice-4-promotion canvas - #9: Introducing parallel omni_*_share_one_node_tree gate when invariant cashed at gate #28 §10 R4 phase plan extended: Phase-1.5 Practice-4-promotion canvas inserted between Phase-1 and Phase-2. §12 reframed Q1-Q5 + Practice 4 as ratified-dispositions audit trail. §3-§7 "Mgr recommendation" labels reframed as "Ratified disposition". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 of 6 tasks
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…with gate #28) Co-authored-by: Cursor <cursoragent@cursor.com>
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…rward-pointer per operator directive 2026-05-13 Operator question: "are we bringing mixed/omni emission into R3 now - if so, what would the interrogation be? stringing together programs across a network - how would that be modeled?" PM scoping read + operator approval (option a + c): - Existing R3 omni-emission: single-program multi-target (Rust + Python + Go + OpenAPI + Markdown + SQL DDL from one .dag per gate #28) - NOT in R3: multi-program coordination across network boundaries from one .dag source. This is R4 territory. Added §3.8 as forward-pointer STUB (parallel to §3.4): - Status STUB; substantive Q-dispositions land via separate R4 canvas - Distinct from path (b) full-stack canvas (PR #2847 = single-program-multi- target; §3.8 = multi-program-coordination) - Cites existing R3 substrate as structural cash: gate #25 OpenAPI, #28 omni- layers-share-one-node-tree, #29 Anthropic wire-serde - 7 deferred probe areas: - Multi-program shape (lens dimension vs substrate carrier) - Wire derivation extension (gate #28 cross-deployment) - Coordination semantics (6th L1 behavior would trigger C1 stop-signal; OR Bind+Effect composition sufficient) - Failure-at-boundary modeling - Idempotency at endpoint (composes with idempotency lens) - Cross-endpoint dimension propagation (extends §2.5.F affected-set) - End-to-end 2-endpoint demonstration falsification probe Open R4 canvas questions enumerated for downstream authoring: - 6th behavior (Coordinate) vs Bind+Effect composition (C1 stop-signal) - Endpoint addressing: substrate carrier vs lens dimension - Failure-recovery composition with fail-closed C-8 discipline PM read: multi-program coordination is the natural completion of omni-emission (N projections × M programs from gate #28's N projections × 1 program). Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
briansrls
added a commit
that referenced
this pull request
May 13, 2026
* docs(r4): full-stack omni-emission canvas (TS + React substrate) Director ratified path (b) canvas dispatch via PM msg_83ce8113 relaying msg_22a1c596 on 2026-05-13. Operator directive: generate full-stack program from one .dag (Rust backend + TS client + React UI + OpenAPI + SQL DDL all from single source). Substrate audit at HEAD: dsl/extdeps/languages/ lacks TS; net-new substrate authoring. Gate #28 omni_layers_share_one_node_tree CONSUMER_ LANDED + PASSING provides the cross-target invariant extension point. Canvas surfaces 5 Director-framed questions: - Q1 TS LanguageSpec shape (parallel-to-Rust vs structural-vs-nominal axis on InhabitantDecl); Mgr-rec Q1-b - Q2 React carrier Shape-A vs Shape-B vs new Shape-F framework-tier; Mgr-rec Q2-a Shape-A - Q3 ingest direction (.dag→JSX vs TS→Component vs bidirectional); Mgr-rec Q3-a single-authority - Q4 cross-target consistency invariant extension (#28 expansion vs new gate); Director disposition required - Q5 lens framework composition (Component as Behavior::Bind vs separate substrate-kind); Mgr-rec Q5-a uniform Practice 4 sketch for new sum types: HookKind 🟡 YELLOW (Custom arm consumer-evidence-required); others 🟢 GREEN. R4 phase plan (5 phases) + 6 Director-pending anti-patterns + cost-of- change accounting (5→1 file per new endpoint). Hard-bound: canvas-only; NO implementation pre-R3 close. Companion is Director-owned path (a) visceral 4-layer TODO demo. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 full-stack canvas — Director-ratified state (msg_7d51b699) Director RATIFIED all 6 dispositions on PR #2847 R4 canvas (msg_7d51b699 via PM msg_1faad154 2026-05-13): - Q1 RATIFY Q1-b: TypingDiscipline = Nominal | Structural on InhabitantDecl - Q2 RATIFY Q2-a: Shape-A — components ARE TS source code (Rust/Axum etc. symmetric precedent) - Q3 RATIFY Q3-a: .dag → JSX single-authority - Q4 RATIFY EXTEND gate #28 (NOT new parallel gate; gate name is layer-count-agnostic — parallel gate = INVARIANTS P1 violation) - Q5 RATIFY Q5-a: Component is Behavior::Bind - Practice 4 HookKind RATIFY 🟡 YELLOW with R4-Phase-1.5 Practice-4- promotion canvas requirement (Mgr authors before Phase-2 dispatch) Director-added anti-patterns §11 #7-#9: - #7: Adding TypingDiscipline arms beyond Nominal | Structural without ratified consumer evidence - #8: Custom HookKind in R4-Phase-2 without Practice-4-promotion canvas - #9: Introducing parallel omni_*_share_one_node_tree gate when invariant cashed at gate #28 §10 R4 phase plan extended: Phase-1.5 Practice-4-promotion canvas inserted between Phase-1 and Phase-2. §12 reframed Q1-Q5 + Practice 4 as ratified-dispositions audit trail. §3-§7 "Mgr recommendation" labels reframed as "Ratified disposition". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — HookKind arm-count framing consistency Cursor 10817 (APPROVE w/ exploratory): §8 said "7-arm closed enumeration" while §12 separately framed "6 standard hooks + Custom(Identifier)". Reframe §8 to match §12: 6 standard-hook arms + 1 user-input boundary arm. Eliminates two-different-coproduct-sizes reading. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — codex BLOCKING substrate-shape corrections Codex review d251b61 — 2 BLOCKING findings on R4 substrate sketch: Finding 1: HookKind incomplete roster. Previous: 6 React-18 standard hooks + Custom(Identifier) — under-enumerated. Fix: 15-arm closed enumeration of all React 18.3 built-in hooks (authority anchor: react.dev/reference/react) — UseState/UseReducer/UseEffect/ UseLayoutEffect/UseInsertionEffect/UseContext/UseRef/UseImperativeHandle/ UseMemo/UseCallback/UseDebugValue/UseDeferredValue/UseTransition/UseId/ UseSyncExternalStore + Custom(Identifier) boundary arm. Dissolution trigger: React version-anchor change (new 18.x/19.x built-in) re-ratifies roster. Finding 2: ComponentBody coproduct treats subcomponents as alternate mode. Previous: ComponentBody = Render { jsx: JSXTree } | Composite { sub_components: ... } Fix: Component.body IS a JSXTree; subcomponents are JSXNode.ComponentRef nodes within the tree, not a separate body mode. Reshape: JSXNode = HtmlElement | ComponentRef | TextNode | ExpressionSlot | FragmentNode Dissolves the prior Render/Composite split — one render tree with component references as tree nodes. Both findings reflect substrate-shape corrections needed before canvas becomes R4 worker authority. §8 Practice 4 table + §12 ratification narrative updated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — cursor 10851 single-authority + sketch typo Cursor APPROVE_WITH_COMMENTS review 10851 — 2 findings: 1. §6 L226 conflicting guidance: "React UI (new Shape-A or Shape-F)" contradicted ratified Q2-a (Shape-A only) + anti-pattern §11 #6. Fix: "React UI (new Shape-A per ratified Q2-a; Shape-F explicitly REJECTED — see anti-pattern §11 #6)". Single-authority restored. 2. §3 L124 self-referential typo: JSXNode.ComponentRef arm declared `component: ComponentRef` (recursive name collision). Rename arm to `ComponentRefNode` with field `component: ComponentName` — a distinct handle type referencing the named Component, not the JSXNode arm. Cascaded rename through §3 comment + §8 Practice 4 table. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — TypingDiscipline fail-closed migration (codex 10864) Codex REQUEST_CHANGES review 10864: §12 Q1 disposition said "Rust/Python/Go default to Nominal", which reintroduces convention/ fallback semantics — missing field interpreted as plausible value instead of failing closed. Violates INVARIANTS P3 + Practice 6. Fix-forward: tighten migration story across §3 / §12 / §10 / §11: - §3 Candidate Q1-b body + §3 Ratified disposition: explicit fail-closed framing — missing field MUST fail compilation; no implicit default - §12 Q1 ratified disposition: atomic migration receipt encoded — same PR adds carrier extension + sets typing_discipline = Nominal on every existing inhabitant + compile-time exhaustiveness test - §10 R4-Phase-1: fail-closed atomic migration framing inline - §11 #10 (new Mgr-derived anti-pattern): explicit ban on implicit Nominal default for existing rows The Q1-b ratification stands; only the migration shape tightens to fail closed per P3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — cursor 10884 exploratory tweaks Cursor APPROVE 10884 with 2 exploratory observations: - L83 Q1-b Cons "lazy migration acceptable" contradicted §12 ratified atomic+fail-closed migration. Reworded to match ratified disposition + cite anti-pattern §11 #10. - L313 Q3-a cited "INVARIANTS P1" for single-authority; the exactly-one-authoritative-place principle is P2 (Boundary Discipline). Fixed citation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — tighten Cost-of-Change citation (cursor 10898) Cursor APPROVE 10898 exploratory: §9 cited "INVARIANTS.md Cost of Change", but the named section lives in CLAUDE.md §"Cost of Change" (the 1-file-edit-per-extension principle); INVARIANTS.md anchors the substantive discipline at P2 boundary + P5 progress-is-dissolution. Reframe citation to point at the canonical CLAUDE.md location + the INVARIANTS.md principle anchors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — per-arm HookKind call signatures (codex BLOCKING canvas:76) Codex BLOCKING canvas:76: Hook.dependencies on the uniform Hook record let UseState/UseRef/UseContext (which don't take dependency arrays) carry meaningless dependency facts AND erased the distinct call signatures of effect/memo/callback/imperative-handle hooks. P1/P2/P6. Fix-forward: drop uniform Hook.dependencies; move call-signature fields into each HookKind arm directly per React 18.3 reference. Each arm now carries exactly the fields its hook takes: - UseState { initial } - UseReducer { reducer, initial } - UseEffect / UseLayoutEffect / UseInsertionEffect { body, dependencies, cleanup? } - UseContext { context_ref } - UseRef { initial } - UseImperativeHandle { ref, factory, dependencies } - UseMemo { factory, dependencies } - UseCallback { callback, dependencies } - UseDebugValue { value, format? } - UseDeferredValue { value } - UseTransition (no args) - UseId (no args) - UseSyncExternalStore { subscribe, get_snapshot, get_server_snapshot? } - Custom(Identifier) Hook record reduces to `{ name, kind: HookKind }`. Prior standalone Effect type dropped (body+cleanup now on UseEffect arm directly). New anti-pattern §11 #11: call-signature fields on uniform Hook record are forbidden — they belong on the per-arm carrier. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r4): R4 canvas — dissolve Lifecycle into UseEffect arm (codex canvas:184) Codex BLOCKING canvas:184: Lifecycle = OnMount | OnUnmount | OnUpdate classified GREEN but the variants are NOT irreducible — they derive from UseEffect arm structure: OnMount ≡ UseEffect { body, dependencies: [], cleanup: None } OnUnmount ≡ UseEffect { body: None, dependencies: [], cleanup: Some(...) } OnUpdate(triggers) ≡ UseEffect { body, dependencies: triggers, ... } Parallel-authority sum violates Practice 4 / P1. Lifecycle reasoning is a derived projection of UseEffect facts, not its own carrier. Fix-forward: - §3 carrier sketch: Lifecycle DROPPED with dissolution receipt comment - §8 Practice 4 table: Lifecycle struck-through, reclassified RED → dissolved; cite codex finding - §2 audit snapshot: clarify Lifecycle + Effect not introduced - §11 #12 (new Mgr-derived anti-pattern): forbid parallel Lifecycle sum alongside UseEffect Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…" per cursor exploratory observation on PR #2884 Cursor review 10956 (non-blocking exploratory): > "the phrase 'TS (Shape-A) + React (Shape-A) projections added' sits under > 'R4 extension scope'; a hurried reader could still read 'added' as > 'already shipped.' If that ambiguity shows up in review chatter, a tiny > edit like 'projections in scope' or 'projections authorized' would > remove the misread without changing meaning." Cursor's verdict was APPROVE; this is the optional polish edit. Tightening: - "TS (Shape-A) + React (Shape-A) projections added" → "TS (Shape-A) + React (Shape-A) projections in scope" - Added explicit framing: "R4-Phase-1..5; NOT shipped at R3-close — authorized for R4 implementation post-R3" Removes the "already-shipped" misread without changing meaning. Aligns with row's CONSUMER_LANDED + PASSING status cell (which refers to current 4-projection set, not the R4-extended N-projection set). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…_service.dag (TODO Item/List/User + mutations) → exercise the existing 4 emitters (Rust backend, SQL DDL, OpenAPI yaml, Markdown docs per src/v3/compiler/src/omni_shape_b_openapi.rs gates #25-#28 CONSUMER_LANDED+PASSING) → emit 4 a (#2848) * WIP: Path (a) full-stack omni-emission visceral demo: write dsl/demos/todo_se * chore: apply cargo fmt (todo_service omni test) Co-authored-by: Cursor <cursoragent@cursor.com> * WIP: Path (a) full-stack omni-emission visceral demo: write dsl/demos/todo_se * test(omni): use counted compile helper for todo_service demo (parity with gate #28) Co-authored-by: Cursor <cursoragent@cursor.com> * demo(todo_service): add example data rows so domain types are inhabited Co-authored-by: Cursor <cursoragent@cursor.com> * test(omni): rustc+probe todo_service backend against canonical routes Co-authored-by: Cursor <cursoragent@cursor.com> * WIP: Path (a) full-stack omni-emission visceral demo: write dsl/demos/todo_se --------- Co-authored-by: Cursor <cursoragent@cursor.com>
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…ry (post-#2847-merge follow-ons) (#2884) * docs(r3+r4): §1.8 row #28 N-projection expansion + WISHLIST §R4.E full-stack-from-one-.dag entry (post-#2847-merge PM follow-ons) Both follow-ons unblocked by R4 path-b canvas merge (PR #2847 squash 1f88306 2026-05-13T08:05:02Z, Director-ratified Q1-b/Q2-a/Q3-a/Q4-extend/Q5-a/Practice-4 + anti-patterns + scope extension). **§1.8 row #28 ledger update** (Task #20 — Director Q4 ratification msg_7d51b699): - Made NAME layer-count-agnostic per Director rationale (current description's enumeration was incidental, not authoritative) - Cited current PASSING projection set (Rust + canonical route + OpenAPI + Markdown + SQL DDL) - Added R4 extension scope: TS (Shape-A) + React (Shape-A) per ratified canvas; test surface extends to N-target consistency - Encoded Director anti-pattern #6 verbatim: introducing parallel `omni_*_share_one_node_tree` gates is INVARIANTS P1 violation **WISHLIST §R4.E entry** (Task #21 — Director-suggested entry text): - Full-stack-from-one-`.dag` with React framework substrate (R4-Phase-1..5) - All 5 Q-ratifications cited (Q1-b TypingDiscipline / Q2-a Shape-A / Q3-a single-authority / Q4-extend / Q5-a Behavior::Bind) - Composes-with notes: R4.A omni-ingestion + R4.B Introspect-lens + R4.C low-level emission + R4.D faithfulness - Phase 1.5 HookKind Practice-4-promotion canvas requirement noted (pre-Phase-2 dispatch per Director) - Distinct from multi-program-coordination canvas (deferred per msg_3bf3df9c; forward-pointer at §3.8) - Connection to R3 path (a) demo PR #2848 (4-layer cash for Rust + OpenAPI + Markdown + SQL DDL projections) Authority chain (verbatim cites): - Operator directive 2026-05-13 + ratification of paths (a)+(b) - Director msg_7d51b699 (Q1-Q5 + Practice 4 + anti-patterns #7+#8 + 5-phase plan) - Director msg_2c1bfb0e (Q6 negative-degree scope extension + Q7 SymbolicCost preservation + anti-pattern #9) - Director msg_3bf3df9c (option C defer disposition for multi-program-coordination) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §1.8 row #28 — disambiguate "projections added" → "in scope" per cursor exploratory observation on PR #2884 Cursor review 10956 (non-blocking exploratory): > "the phrase 'TS (Shape-A) + React (Shape-A) projections added' sits under > 'R4 extension scope'; a hurried reader could still read 'added' as > 'already shipped.' If that ambiguity shows up in review chatter, a tiny > edit like 'projections in scope' or 'projections authorized' would > remove the misread without changing meaning." Cursor's verdict was APPROVE; this is the optional polish edit. Tightening: - "TS (Shape-A) + React (Shape-A) projections added" → "TS (Shape-A) + React (Shape-A) projections in scope" - Added explicit framing: "R4-Phase-1..5; NOT shipped at R3-close — authorized for R4 implementation post-R3" Removes the "already-shipped" misread without changing meaning. Aligns with row's CONSUMER_LANDED + PASSING status cell (which refers to current 4-projection set, not the R4-extended N-projection set). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks done
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…R4.A compose bullet + r3-program-plan.md anti-pattern #6→#9 fix (codex BLOCKING on PR #2884) (#2898) Two fix-forwards on merged PR #2884: 1) WISHLIST.md:189 (codex BLOCKING) — R4.A compose bullet wording implied R4.E gains bidirectional TS extdeps + React component-source ingest, which conflicts with ratified Q3-a (`.dag` → JSX single-authority; canvas §5 + §12; INVARIANTS P2). Rewritten to: R4.A is orthogonal axis; R4.E stays `.dag` → JSX single-authority per Q3-a; any TS/React source ingest is R4.A scope (or migration-tooling concern per Q3-c rationale) with no source-of-truth authority over `.dag`. 2) docs/r3-program-plan.md:256 row #28 (codex non-blocking improvement) — anti-pattern citation #6 → #9 (canvas §11 numbering: #6 is `Shape-F` introduction; #9 is parallel `omni_*_share_one_node_tree` gate — the latter is what the row #28 description references). Authority chain: - Codex BLOCKING review on PR #2884 sha 861407f at 2026-05-13T09:07:43Z (inline comment WISHLIST.md:189 + non-blocking improvement) - Director ratification msg_7d51b699 Q3-a (canvas §5 + §12) - Canvas §11 anti-pattern #9 (Director-added per msg_7d51b699) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
briansrls
added a commit
that referenced
this pull request
May 13, 2026
…5.4 + 9 thesis gap-fills (#2849) * docs(r3): §3.4 — full-stack-from-one-.dag forward-pointer stub (Director msg_428b032e pre-stage disposition) Per Director msg_428b032e pre-stage disposition on operator directive 2026-05-13 (full-stack-from-one-.dag program + path (a)+(b) ratified): stub adds §3.4 as pointer-only forward-pointer; substantive Q-dispositions land post-canvas-ratification. Structural cash cited (Director-verified 2026-05-13 §1.8 audit): - Gates #25/#26/#27/#28 all CONSUMER_LANDED + PASSING - Path (a) Director-direct demo work-item adhoc-e9bb6ef1-b4d - Path (b) Substrate-Mgr R4 canvas at docs/design-r4-full-stack-omni-emission-canvas.md Stub framing per Director guidance: "no Q-claims; current entry is forward-pointer for thesis-coherence visibility per operator directive 2026-05-13". Probes are deferred placeholders (clearly labeled); substantive answers land when path (a) demo PR + path (b) canvas PR surface. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §2.5.F + §5.4 — affected-set lens + compiler-as-data residual interrogation per operator directive 2026-05-13 Two new interrogation sections per operator follow-up 2026-05-13: §2.5.F Cross-module subtle-dependency detection via affected-set lens - Frames affected-set lens as the structural mechanism catching diff-driven cross-module subtle deps (complement to static lens reads in §2.5.E) - Cites gate #103 ci_uses_affected_set_selection DECLARED + Slice 7 T-WAD - Cites docs/design-affected-set-lens.md substrate-shape ratification - 5 probe groups: CI integration site + SHA-diff input + dimension-only catch example + cardinality-vs-transitive-downstream + 4 falsification probes - PM read: affected-set is THE structural cash for cross-module subtle deps; static + diff lens reads compose to give omni-correctness story §5.4 Compiler-as-data residual — operator-explicit probe set - Strong-form probes for "compiler is pure data yet?" operator framing - Cites operator 2026-05-09 verbatim ("0 hand-Rust including tests AND stage0") - Cites SELF_HOSTING.md §1 bootstrap-seed framing as weak-reading anchor - 5 sub-areas: stage0 edits / hand-Rust count / non-Rust hand-maintained / pure-data thesis-state / R3-close honest framing - Strong vs weak reading distinction explicit; reconciling is itself an R3-close question - Anti-pattern: silently shipping with weak reading while citing strong Both sections are probes-only (no decided framing); R3 close ratification will land via Director + operator review. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): thesis-coverage sweep — 9 new interrogation sections per operator audit 2026-05-13 Operator coverage audit identified 9 thesis-claim gaps in interrogation doc. This commit fills all 9: §1.6 Tier 1 mechanics (THESIS.md:168-173) - Coercion = emission / Ownership / Grounding completeness probes - Grounding-completeness is highest-load-bearing (structural homomorphism vs name-keyed table; fail-closed on ungrounded) §1.7 Tier 2 runtime safety (THESIS.md:175-176) - Division-by-zero / OOB / force-unwrap / partial-functions probes - Per-class: proven safe or made total — no handwaving §2.6 Substrate-shape specifics (THESIS.md:198-203) - 6 connectives (Atom/Conj/Disj/Arrow/Cardinality/Instantiation) - 5 behaviors (Value/Transform/Branch/Loop/Bind) - C1-class stop-signal protocol probes §2.7 Modeling discipline (THESIS.md:415-419 + :359) - Every type has a structural consumer - Typed enums not String/Bool proxies at boundaries - No fabrication sentinels (__BUG_* / __EMIT_BUG_*) - No duplicate record shapes (one type per concept) - Rust-tests are a language smell (SG-0 EXPECTED_HAND_AUTHORED_TEST probe) §3.5 L6 every-form-every-target (THESIS.md:181) - Distinct from L5 cross-target consistency - Density of (structural-form × target) emit-matrix; per-target gaps §3.6 L7 algebraic-laws (THESIS.md:182) - Operations obey declared algebraic laws - Per-algebra-carrier law coverage probes; cross-target consistency §4.3 Concept unifications (THESIS.md:184-188) - Coercion cost = complexity (parallel-authority check) - Coercion = emission (refs §1.6) - Target lang spec = transport spec = interpreter runtime - Idempotency + cancellation + redundancy = algebraic simplification §5.5 Free consequences (THESIS.md:205-210) - Auto-memoization from purity + cost - Incremental cross-run execution (composes with §2.5.F affected-set) - Cross-language optimization from shared cost algebra §6 reorganized as "The user-experience / adoption promises" umbrella: - §6.1 Show the correct code (existing content) - §6.2 Audience duality / opt-in depth (THESIS.md:307-321) - Core-language approachability + opt-in advanced surface - Per-audience demo fixtures (fixture_compiler_nerd_canonical + fixture_integration_canonical) - §6.3 Adoption model — economics, not enforcement (THESIS.md:323-346) - Every program gets guarantees (no opt-out syntax) - Leaving the stack (in-language namespacing vs outside-language) - LOC overhead vs alternatives + percentage-all-green metric Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §3.7 verification-machinery interrogation (testgen / integration / mocks / dry-run) per operator audit 2026-05-13 Operator follow-up after thesis-coverage sweep: testgen interrogation surface. Added §3.7 "The verification-machinery promises" with 5 sub-areas: §3.7.a Testgen — structural coverage derived from code (THESIS.md:356-358) - Where testgen lives + .dag vs hand-Rust - Per-type inhabitant + coercion test generation (SELF_HOSTING.md §2 L1.5) - Coverage monotonic with declared structure - Spot-check vs exhaustive (TESTING.md:343 reshape directive) §3.7.b Integration testing (TESTING.md:128 + :118) - compile_to_dag(fixture) standard form - Heavy integration tests as exception - Mock-over-compile anti-pattern probe (TESTING.md:84) - Cross-target coverage (Rust + Python + Go) §3.7.c Mocks / dependency injection by construction (THESIS.md:367) - Effects as explicit parameters; substituting fake parameter IS the mock - No mock-framework / test-double-DSL / monkey-patching - No-flaky-tests probe (CI history audit) - Ambient-capability falsification probe §3.7.d Dry-run / structural execution traces - dag run --dry-run vs IntrospectApplication lens vs implicit-via-purity - Effect-shape preview + cost-preview composition with §1.2 - Affected-set composition (per §2.5.F) - Simulated-inputs vs actual-execution distinction - HTTP-POST falsification probe (does request happen) §3.7.e Verification-machinery composition - Unified question: do the 4 surfaces share one substrate-read? - Falsification: per-bug-class which surface catches; gap-class identification R3-close framing: 4 surfaces should be lens-compositions over same substrate, not parallel pipelines. R3 close demonstrates adding new verification dimension is one lens, not separate pipeline. Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §2.5.F.1 — affected-set minimality definition + 35-scenario comprehensive examples table per operator audit 2026-05-13 Operator request: "i would think of normal code changes and make the table/questions comprehensive." Added §2.5.F.1 with: 1. Formal minimality definition (`docs/design-affected-set-lens.md:44` cited verbatim): "Strictly smaller than transitive-downstream — but only relative to the structural dimensions whose values actually changed." - Minimal = minimal among soundly-derivable; NOT theoretically-optimal - Soundness + completeness definitions explicit - Fail-closed posture: lens fails OVER-inclusive (safe), never UNDER-inclusive 2. 35-scenario comprehensive examples table spanning: - Format-only / comment-only / identity-only changes (1-4) - Value / algorithm / effect changes (5-9) - Type signature changes — required arg / optional arg / removal (10-12) - Field add / remove / rename / type-change (13-16) - Refactor: extract / inline (17-18) - Add new code / delete unused / delete with consumers (19-22) - Parallelism shape (23) - Test-only / doc-only (24-25) — including test-doesn't-propagate-forward - CI / build / cross-module imports (26-27) - Dependency bump / generated regen (28-29) - Fail-closed: opaque ExecuteCommand / PB-Runtime kernel (30-31) - Compile-time-only / lens additions / algebra-law / substrate-extension (32-35) 3. Falsification-probe pattern per-scenario: - Soundness probe: ∅-expected should produce ∅ - Completeness probe: flagged-consumers should match expected set - Provability-boundary probe: fail-closed scenarios should not UNDER-include 4. Honest framing on theoretical-vs-observable minimum + R3-vs-R4 trajectory. Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §5.4.d/e tighten — interrogate against committed 0-floor target, not negotiate between readings (codex BLOCKING on PR #2849) Codex finding (review 10874) verbatim: > "§5.4 currently reopens the zero-hand-Rust target instead of interrogating > against it. Tighten that section so the weak/bootstrap-seed framing is > treated only as contrary evidence to explain, not as an alternative > acceptable close criterion." Finding is structurally correct. design-pure-bootstrap-zero.md is unambiguous authority on the committed target: - :41 "Goal: zero hand-authored files in v3's source tree. Better than v2's 1-residual." - :43 ≤5-floor retracted; 0-floor is the live shape - :210 hand-authored-vs-generated boundary: trampolines are 0 if generated; hand-authored bootstrap-seed is NOT acceptable Rewrite §5.4.d: - Title changed to "interrogate against the committed 0-floor target" - Cites design-pure-bootstrap-zero.md:41 + :210 verbatim as authority - SELF_HOSTING.md "bootstrap seed" framing reconciled as describing POST-0-floor functional shape, NOT alternative R3-close criterion - Bootstrap-seed Rust acceptable IFF machine-emitted from .dag (per :210) - Removed "strong vs weak reading" negotiation framing - Probes now interrogate against single committed target: - PB-0 census count at HEAD (target: 0) - Per-survivor named-retirement-schedule - Bootstrap-seed claims verified as machine-emitted, not hand-authored - design-pure-bootstrap-zero.md:191 STOP-condition probe (N=0 resolution outside src/v3/) Rewrite §5.4.e: - Removed "R3 close MAY claim..." alternative-reading framing - Hand-authored survivors with named-retirement-schedule are acknowledged R3 debt against the 0-floor target, NOT acceptable close criterion - Anti-pattern reframed: bootstrap-seed Rust acceptable IFF generated; otherwise 0-floor debt; R3 close framing must cite census + per-survivor disposition (machine-emitted OR named-retirement) Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §2.5.F.1 — rename Soundness/Completeness → No-spurious-inclusion/No-missed-inclusion (cursor exploratory observation on PR #2849) Cursor review 10892 flagged terminology ambiguity (non-blocking, exploratory): > "the pair labeled 'Soundness' / 'Completeness' is easy to misread against > usual static-analysis vocabulary (where 'sound' often means 'no false > negatives' for may-analysis). The substance matches the fail-closed > over-approximation story in docs/design-affected-set-lens.md (lines 44-92 > in the current tree); renaming for less ambiguity would be polish only, > not a merge blocker." Rename for clarity: - Soundness → No-spurious-inclusion (the "exclusion-correctness" direction) - Completeness → No-missed-inclusion (the "coverage" direction) Plus explicit note: standard static-analysis conventions for sound/complete invert under fail-closed over-approximation, so the lens correctness target is "No-missed-inclusion (strict)" + "No-spurious-inclusion (relative to provability)" — over-inclusion on UNKNOWN delta is intentional and safe. Falsification probe labels updated correspondingly. Audit-document terminology clarity warranted even though non-blocking. Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §3.8 stub — multi-program / network-coordinated emission forward-pointer per operator directive 2026-05-13 Operator question: "are we bringing mixed/omni emission into R3 now - if so, what would the interrogation be? stringing together programs across a network - how would that be modeled?" PM scoping read + operator approval (option a + c): - Existing R3 omni-emission: single-program multi-target (Rust + Python + Go + OpenAPI + Markdown + SQL DDL from one .dag per gate #28) - NOT in R3: multi-program coordination across network boundaries from one .dag source. This is R4 territory. Added §3.8 as forward-pointer STUB (parallel to §3.4): - Status STUB; substantive Q-dispositions land via separate R4 canvas - Distinct from path (b) full-stack canvas (PR #2847 = single-program-multi- target; §3.8 = multi-program-coordination) - Cites existing R3 substrate as structural cash: gate #25 OpenAPI, #28 omni- layers-share-one-node-tree, #29 Anthropic wire-serde - 7 deferred probe areas: - Multi-program shape (lens dimension vs substrate carrier) - Wire derivation extension (gate #28 cross-deployment) - Coordination semantics (6th L1 behavior would trigger C1 stop-signal; OR Bind+Effect composition sufficient) - Failure-at-boundary modeling - Idempotency at endpoint (composes with idempotency lens) - Cross-endpoint dimension propagation (extends §2.5.F affected-set) - End-to-end 2-endpoint demonstration falsification probe Open R4 canvas questions enumerated for downstream authoring: - 6th behavior (Coordinate) vs Bind+Effect composition (C1 stop-signal) - Endpoint addressing: substrate carrier vs lens dimension - Failure-recovery composition with fail-closed C-8 discipline PM read: multi-program coordination is the natural completion of omni-emission (N projections × M programs from gate #28's N projections × 1 program). Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(r3): §2.5.F — fix design-doc authority cite (operator BLOCKING on PR #2849:352) Operator BLOCKING finding (verbatim): > "The changed status says docs/design-affected-set-lens.md is 'substrate- > shape ratified,' but that design doc explicitly says it is not a substrate- > shape ratification or §1.8 gate addition, so the close audit would rest on > a false authority (INVARIANTS P1/P2)." Finding verified against design-affected-set-lens.md:7 verbatim: > "Scope: design framing + 5 worked examples. Not a substrate-shape > ratification; not a §1.8 gate addition. Prototype lives under gunbc#2699 > worker scope." §2.5.F text rewritten to accurately reflect the design doc's actual status: - Was: "substrate-shape ratified; consumer pattern is CLI / agent / IDE..." - Now: "design framing + 5 worked examples; NOT a substrate-shape ratification, NOT a §1.8 gate addition (per design doc §Scope line 7 verbatim). Substrate-shape ratification + §1.8 gate landing pending. Consumer-pattern sketch: ... Prototype scope at gunbc#2699." Preserves INVARIANTS P1/P2 (single authority; no false ratification claim). Holding for operator review/approval per directive 2026-05-13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 17, 2026
Merged
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
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
This PR addresses three critical issues in the Value type system and code generation:
Value::is_empty()method - Adds semantic emptiness checking across all Value variants<MOCK>placeholders with explicit panics to surface real bugsis_empty()method instead of fragile string-only checksKey Changes
Core IR (
core/ir/src/value.rs)Value::is_empty()method with variant-specific semantics:Unit,Skipped→ always emptyStr,List,Map,Secret→ check inner emptinessBool,Int,Json,Request,Response→ never empty (data by existence)Code Generation (
core/codegen/src/testgen/codegen.rs)value_to_rust_literal():filter_mapon List that silently dropped non-string elements with proper recursive serializationValue::Mapsupport with proper BTreeMap construction_ => "<MOCK>"to explicit panic forRequest/ResponsevariantsTest Mocking (
core/test/src/mock_spec.rs)value_to_code(): Applied same fixes asvalue_to_rust_literal()for consistencyOutputMatcher::NonEmpty: Simplified assertion fromas_str().map(|s| s.is_empty()).unwrap_or(false)tois_empty(), making it type-aware and supporting all Value variantsGenerated Tests
is_empty()assertion formatImplementation Details
The panic-on-serialization approach is intentional. Previously,
RequestandResponsevariants would silently degrade to<MOCK>strings, hiding real bugs in test generation. Now they fail loudly, forcing explicit handling or use ofValue::Skippedas a placeholder.String escaping now properly handles both backslashes and quotes, preventing malformed Rust code generation.
Closes
NonEmptycodegen type-awarevalue_to_rust_literalcatch-all with panicValue::Listfilter_map silent droppingValue::is_empty()method tocore/irhttps://claude.ai/code/session_015sAGUqUgBu22chUq2qftdq