Version. 0.1
Date. 2026-05-13
Status. Discovery-style investigation. Triggered by the Operator's question following the RFP deep-dive investigation v0.1: does Claude Code's newly-shipped /goal slash command empower Loomworks's render potential if a REQ-spec is directed to produce an application using Claude Code? The question is timely because /goal shipped two days before this investigation was filed (Claude Code v2.1.139 on 2026-05-11) and because the architectural primitive it embodies — agent loops to verifiable end-state — is the same primitive Loomworks's methodology was built around.
Author. Claude.ai (research and consolidation layer). Operator: Marvin Percival.
Disposition. Filing as Discovery-style investigation. Names a concrete external render specialist candidate (Claude Code via /goal) and an integration pattern (two-stage render pipeline: spec-to-tests, then /goal-driven implementation). Cross-references queued directions v0.14 §15 (external render specialists deferred work) and the discovery-shape-as-specification document at v0.4. Companion investigations named in §10 (REQ-spec-to-acceptance-test materialization specialist; competitive-positioning update to structural-defensibility) are flagged for follow-on sessions, not produced here.
This investigation answers the Operator's question: yes, Claude Code's new /goal command materially empowers a specific render-specialist class for Loomworks — the class that renders a shape-as-specification (REQ-spec or equivalent) into a working application. The path is not direct; it requires a two-stage pipeline where Loomworks first materializes the specification into a transcript-observable acceptance-test suite, then drives Claude Code's /goal to make implementation satisfy those tests. The architectural placement is as one external render specialist (the code-from-shape-as-specification specialist), attaching at the Render-room specialist boundary already specified in Loomworks methodology — not as a replacement for the Render room itself.
A deeper recognition surfaces: the rapid convergence of major AI labs on the same primitive (/goal shipped in OpenAI Codex CLI, then Claude Code via GitHub issue #56085 within seven days, then Hermes Agent) is industry validation that agent-loops-to-verifiable-end-state is becoming the cross-vendor architectural pattern. This is the same primitive Loomworks's four-room pipeline (Memory → Manifestation → Shaping → Rendering) was built around. The convergence does not invalidate Loomworks; it sharpens its positioning: capability layers are commoditizing at speed, methodology layers are not.
Operator decision needed: whether to elevate Claude-Code-as-render-specialist from "candidate external render specialist" to "preferred external render specialist for the code-from-spec class" in queued directions v0.15. The investigation makes the case for elevation but does not unilaterally update queued directions; that is a separate CR.
In scope: mechanics of /goal, fit assessment against REQ-spec, two-stage render pipeline pattern, architectural placement in Loomworks methodology, industry convergence recognition. Out of scope: the materialization specialist itself (named as companion investigation), competitive-positioning rework (named as companion investigation), Phase-NN execution planning for any of this.
The Operator's question, asked terse and directive in chat: does the new /goal option in Claude Code empower the render potential of Loomworks if the REQ spec is directed to produce an app using Claude Code?
The question is layered. It assumes the Render room exists in Loomworks methodology (it does, as the fourth room). It assumes external render specialists are part of the Render-room architecture (they are, named in queued directions v0.14 §15 as deferred work). It assumes REQ-spec — the Forge SAE managed-specification format preserved as a methodological artifact after Forge closed — is a candidate input format for such a specialist (consistent with shape-as-specification, per discovery v0.4). And it assumes Claude Code's /goal is a candidate render mechanism downstream of all that.
The answer is yes in substance, with three architectural pieces that have to exist around /goal for the path to land. The investigation walks each.
/goal actually is
The /goal command shipped in Claude Code v2.1.139 on 2026-05-11, with public-facing documentation at code.claude.com/docs/en/goal. Mechanics, drawn from Anthropic's documentation and corroborated by independent technical writeups:
The Operator types /goal followed by a completion condition (up to 4,000 characters). Claude Code begins working immediately — no follow-up "now do it" prompt is needed. After every turn Claude takes, a separate model — Claude Haiku by default — reads the conversation transcript and judges whether the condition has been met. If not, Claude starts another turn instead of returning control to the user. The goal clears automatically once the condition is met. The Operator can run /goal with no arguments at any point to see turns elapsed, tokens spent, and the evaluator's most recent reason (a one-line judgment such as "two test files still failing in auth/refresh_token_test.py"). To stop early, the Operator types /goal clear (with aliases stop, off, reset, none, cancel).
Three mechanical constraints are load-bearing for the rest of this investigation. First, the evaluator reads the transcript only — it does not run commands or read files independently. Conditions must be phrased so Claude's own output in the transcript can demonstrate they are met. Second, the condition is capped at 4,000 characters. Third, /goal runs only in workspaces where the trust dialog has been accepted (the evaluator is part of the hooks system), and /goal is unavailable when disableAllHooks is set or when allowManagedHooksOnly is set in managed settings.
Pairing with auto-mode (which approves tool calls automatically per turn) makes /goal fully unattended: auto-mode removes per-tool prompts, /goal removes per-turn prompts. The two are complementary.
The shipping history is itself relevant. OpenAI's Codex CLI shipped /goal in version 0.128.0. GitHub issue #56085 was filed in the Claude Code repository on 2026-05-04 requesting parity, labeled "high priority," and closed seven days later when the command shipped in v2.1.139. The Nous Research Hermes agent supports the same command with shared naming. The independent commentary noted "this is the industry settling on a shared interface for one thing: an agent that runs in a closed loop until a measurable end-state is reached, without asking you for permission every step."
That recognition — that the industry is converging on a shared primitive — is taken up properly in §8. For now it is enough to note the primitive is real, named, and shared across vendors.
/goal align well
The alignment is closer than the surface comparison would suggest. The REQ-spec format and the /goal mechanism were built for different purposes by different people at different times, yet they share a structural commitment that turns out to be load-bearing in both contexts.
The first alignment is on testable atomicity. Forge SAE's induction discipline — atomicity, testability, no compound requirements, terminal-state clarity — was developed as a forcing function on specification quality during the Forge era. The discipline solved a specific problem: under SAE-style induction, requirements that were vague or compound failed the induction cycle and triggered remediation loops. The discipline survives in the methodological artifact preserved after Forge closed (the forge-spec skill). The /goal mechanism exposes the same problem in a different domain: the most-cited failure mode in /goal's first week was loose constraint phrasing. The widely-shared developer-community summary captured the failure pattern bluntly: "Most people are using /goal wrong. They write 'make no mistakes'. And pray." REQ-NNN rows are by construction immune to this failure mode. The Forge induction discipline was solving in 2025 the exact problem /goal exposes in 2026.
The second alignment is on stated checks. REQ-spec rows in the Forge format typically include not just the requirement but how the requirement is verified — an acceptance criterion or test reference. The Anthropic documentation for /goal names exactly this structure: "A condition that holds up across many turns usually has: one measurable end state — a test result, a build exit code, a file count, an empty queue; a stated check — how Claude should prove it, such as 'npm test exits 0' or 'git status is clean'; constraints that matter — anything that must not change on the way there." The REQ-spec's verification-clause discipline maps directly onto /goal's stated-check requirement.
The third alignment is on constraint preservation. Forge SAE's spec format included constraints alongside positive requirements — things that must not be violated during implementation. The /goal mechanism explicitly supports constraint clauses ("without modifying any file outside /auth" is the canonical enforceable example). Both formats treat constraints as first-class.
The fourth alignment, and the deepest, is structural. The Loomworks four-room pipeline (Memory → Manifestation → Shaping → Rendering) terminates at a Rendering room that produces deliverable artifacts from a shaped specification. The shaped specification names the end-state; the render specialist produces against it; the verifier confirms closure. This is structurally identical to the /goal primitive: declared condition, autonomous iteration, separate-model verifier. The Loomworks methodology developed this pattern independently before /goal existed. The convergence is not coincidence — it is two parallel attempts to specify the same architectural primitive.
/goal do not align cleanlyThree gaps. Each requires architectural work to close, and each generates a corresponding Loomworks-internal specialist.
The first gap is the 4,000-character cap on the /goal condition. A real REQ-spec for a non-trivial engagement has dozens to hundreds of REQ-NNN rows. The Forge example most directly preserved in project knowledge — the Enrollium spec — runs at v3.1 with substantial scope; the FarmGuard spec has a v0.1 shortform and a v3.1 long form. Neither would fit verbatim into a 4,000-character /goal condition. The render flow cannot pipe REQ-spec directly into the condition; the condition has to be a bundled abstraction over the spec.
The second gap is the transcript-observability constraint. REQ-NNN like "REQ-042: The system SHALL validate that submitted email addresses conform to RFC 5322" is not transcript-observable as written. The evaluator reading the transcript cannot determine from the requirement text alone whether REQ-042 is satisfied; it needs to see Claude run a test that demonstrates RFC 5322 conformance and report the exit code. The REQ-spec, in other words, must be materialized into a runnable test suite before /goal can verify against it. This materialization step is real, non-trivial work.
The third gap is long-running drift. The /goal documentation and independent commentary both warn about multi-hour runs losing alignment if the specification is refined mid-execution. "Stale context. Long-running goals can drift from the original spec if the codebase changes mid-loop. Pause and reset rather than letting it continue against old context." This is a discipline question more than an architectural one: at the alpha stage of Loomworks's own development, the Operator-bound approval discipline already protects against concurrent shape-and-render — the Operator settles the spec, then dispatches the render. But the protection is procedural rather than mechanical.
These three gaps collectively imply: the bridge between REQ-spec and /goal is not a one-line invocation. It is a two-stage pipeline with specific work happening at each stage.
The architectural pattern that closes the three gaps:
Stage one: materialization. A Loomworks-internal specialist (call it the spec-to-test materialization specialist for now; naming is provisional) consumes the shape-as-specification artifact produced by the Shaping room. For each REQ-NNN row (or equivalent unit of specification), the materialization specialist produces one or more runnable acceptance tests. The test artifacts are emitted as a coherent test suite in the target language and test framework, with traceability from each test back to the REQ row it verifies. The materialization specialist is itself a render specialist in Loomworks's vocabulary — it renders specification into tests — but its target is test code, not application code.
Stage two: implementation. The render specialist that invokes Claude Code constructs the /goal condition by bundling the materialized test suite into a single transcript-observable check. The condition takes a canonical shape: "all acceptance tests in tests/acceptance/ pass when invoked as pytest tests/acceptance/ and the test command exits with code zero, without modifying any file in tests/acceptance/ or any file in tests/golden/." The render specialist then dispatches Claude Code, the /goal mechanism drives implementation iteratively, and the Haiku evaluator confirms closure when all acceptance tests pass.
The two-stage structure has three properties worth naming.
It is resilient to the 4,000-character cap. The condition references the materialized test suite by path; the test suite itself can be of arbitrary size. The cap binds the condition's verbosity, not the specification's depth.
It is resilient to the transcript-observability constraint. The materialization step does the translation from "what the system shall do" (REQ language) to "what command demonstrates the system does it" (test language). The evaluator reads the test result in the transcript without needing direct file access.
It is resilient to spec-and-implementation drift. The acceptance test suite, once materialized, is the locked specification surface for the duration of the /goal run. Any specification change during the run is procedurally a re-materialization, which produces a new test suite and a new /goal run — not a mid-flight drift.
The most important framing recognition in this investigation, which the body of the investigation has been building toward: Claude Code with /goal is one external render specialist, attaching at the Render-room specialist boundary that Loomworks methodology already specifies. It is not the Render room. It is not the Render-room substrate. It is a specialist of a particular class — the code-from-shape-as-specification class — that fits into a slot the methodology already provides.
The extensibility-first principle, named in the queued directions and recognized through Phase 47–49 build work, applies here. The Render room's specialist boundary is the contract surface specialists attach at; the methodology does not enumerate specialists in advance. Claude Code with /goal is now a credible candidate for the code-from-spec specialist slot. The same slot may have other candidate specialists in future (OpenAI Codex CLI with its /goal; Nous Research Hermes with its /goal; future tools that ship the same primitive). The methodology should not bind to any single one.
The materialization specialist from §5 stage one is itself a Loomworks-internal specialist, not external. It belongs to the Render room as a pre-stage to the external code-rendering specialists. The composition is: Shaping room produces shape-as-specification → Render-room materialization specialist (Loomworks-internal) produces acceptance-test suite → Render-room external code specialist (Claude Code via /goal, or alternative) produces implementation against tests.
This composition preserves three Loomworks principles intact.
It preserves the engagement-Memory boundary. The shape-as-specification belongs to its engagement's Memory; the materialized test suite belongs to the same engagement's Memory; the implementation belongs to the same engagement's Memory. Nothing crosses to a different engagement's Memory.
It preserves the Operator-authority principle. The Operator approves the shape-as-specification before materialization; the Operator approves the materialized test suite before dispatch; the Operator approves the rendered implementation before any state transition. /goal runs autonomously within a single Operator-bounded segment.
It preserves the plain-terms-discipline-protects-methodology-nouns. The Render room, the shape-as-specification, the render specialist boundary — all stay as first-class methodology nouns. Claude Code's /goal is a technical artifact attaching at one slot; it does not redefine the methodology vocabulary.
Queued directions v0.14 §15 (per memory) carries external render specialists as deferred work. This investigation does not move the deferred work to active; that is a separate Operator decision and would be filed as a CR amendment to queued directions if elevated. What this investigation does is make the deferred work concrete in a way it was not before.
Before this investigation, the external render specialists line in queued directions was a category placeholder. The category was real, the methodology slot was specified, but the candidate specialists were notional — some future tool that does render-from-spec. After this investigation, the category has at least one concrete candidate of high present-day capability (Claude Code with /goal), with at least two cross-vendor alternatives at substantially equivalent capability (Codex CLI, Hermes), and with an articulated integration pattern (the two-stage pipeline of §5).
The Operator decision named in the plain-language summary is whether to elevate this candidate from "speculative future work" to "preferred external render specialist for the code-from-spec class, pending integration spike." Elevation would not move execution into a current Phase; it would update the queued-directions framing so that future Phase scoping treats Claude-Code-as-render-specialist as the assumed default rather than as one option among many.
A consideration worth surfacing here: the cross-vendor convergence on /goal reduces the lock-in risk of elevating one candidate. If /goal becomes the cross-vendor standard primitive, then the integration pattern is portable across Claude Code, Codex CLI, Hermes, and successors. The Loomworks-internal materialization specialist would not need to be rewritten when the external specialist changes. The methodology bet on the primitive is independent of the vendor bet on the specialist.
This section surfaces the deepest recognition the investigation produces, distinguished as new synthesis rather than as restatement of established knowledge.
The industry has converged on a shared architectural primitive in the last six weeks. OpenAI's Codex CLI shipped /goal first. Claude Code shipped /goal within seven days of the GitHub issue requesting parity. Hermes Agent supports the same naming. Independent commentators have named the convergence explicitly: agent-loops-to-verifiable-end-state is the cross-vendor architectural pattern the industry has settled on.
This primitive is structurally identical to the architectural primitive Loomworks's four-room pipeline (Memory → Manifestation → Shaping → Rendering) was built around. Declared shape names the end-state. Render specialist produces against it. Verifier confirms closure. The convergence is not coincidence; it is two parallel attempts to specify the same primitive, one from the developer-tools direction (Codex CLI, Claude Code, Hermes) and one from the engagement-methodology direction (Loomworks, FORAY, OVA).
The strategic implication is one the Operator has been articulating throughout the build: as AI builders become radically more capable, the requirements specification layer becomes the single point of leverage. The industry convergence on /goal validates this exactly. The capability layer (model strength, tool use, autonomous loops) is commoditizing at speed across vendors. The leverage layer (what makes the loop converge on the right end-state) is methodology — atomicity, testable acceptance criteria, constraint preservation, Operator-bound approval at decision points.
Loomworks's positioning thesis — methodology over capability — is sharpened, not weakened, by this convergence. The capability layer is becoming a substrate every serious vendor provides. The methodology layer is where Loomworks built. The Hypercubic.ai competitive recognition from the RFP deep-dive investigation v0.1 gets recontextualized: Hypercubic positions on AI-driven legacy code analysis (a capability claim); the right Loomworks positioning is methodology that makes any downstream capability — including Claude Code's /goal, including Hypercubic's AI, including future specialists not yet shipped — produce work that converges to the right end-state. Methodology is what makes the loop close on the correct end-state, not just an end-state.
The Anthropic-Claude-modernizes-COBOL announcement on 2026-02-23 (which dropped IBM's stock 13%) was the capability-side recognition. The cross-vendor /goal convergence is the architectural-primitive-side recognition. Both arrive within months of each other. The window for Loomworks to establish methodology positioning before the methodology layer itself commoditizes is the relevant timing recognition — and the window is open now but will not stay open indefinitely.
Three competitive facts have shifted since the RFP deep-dive investigation v0.1 filed two days ago.
The first is that Claude Code with /goal is now itself a directly-usable external render specialist of unusually high capability, available today via npm install. Any modernization engagement Loomworks pursues can integrate Claude Code as the code-rendering layer. The capability gap between Loomworks alone and Loomworks with Claude Code is substantial. The competitive landscape has to be drawn with Claude Code inside the dotted line, not outside it.
The second is that Hypercubic.ai's positioning, named in the RFP investigation as the closest competitive match, becomes structurally weaker against the convergence recognition. Hypercubic markets capability ("Agentic AI for Mainframe Modernization") in a world where capability is becoming a vendor-neutral substrate. The marketing claim is true today and will be increasingly less differentiating tomorrow. The Loomworks counter-positioning — methodology that makes any capability layer produce the right end-state — is structurally stronger over the relevant time horizon.
The third is that the federal procurement targets named in the RFP deep-dive (NLM SBIR Phase I, DoW SBIR DON26BZ01-NV013 on re-release, CMS Medicaid Enterprise state procurements, VA T4NG VistA sustainment) gain a more credible technical narrative. The proposal narrative for any of these now includes a concrete render path: the Loomworks methodology produces a shape-as-specification; the spec is materialized into acceptance tests; Claude Code with /goal drives implementation to closure. The end-to-end story is no longer "Loomworks's methodology will be paired with a future render mechanism;" it is "Loomworks's methodology integrates with Claude Code (available today), with Codex CLI (available today), or with any future specialist meeting the shared /goal interface."
This investigation does not produce the rewrite of the structural-defensibility positioning; that is the third companion investigation named in §10. But the recognitions above name what the rewrite would carry.
Two follow-on investigations are named for separate sessions rather than produced here. The named investigations are scoped now, deferring production, so the disposition is clear.
The first companion investigation is the materialization-specialist investigation. Scope: walk the design of the Loomworks-internal specialist that converts shape-as-specification (REQ-spec format or equivalent) into runnable acceptance-test suites. Cover the target language and test framework abstractions (the specialist must support pytest, vitest, and likely JUnit at minimum given the engine and OL stacks); the traceability discipline from REQ row to test; the failure modes when REQ rows are too vague to materialize cleanly (which feeds remediation back into the Shaping room); and the engagement-Memory placement of materialized test artifacts. This investigation should produce a draft skill specification, not implementation.
The second companion investigation is the structural-defensibility positioning update. The existing structural-defensibility positioning document at v0.1 (per project knowledge) predates the cross-vendor /goal convergence by some weeks. The update walks: the convergence recognition from §8 above; the recontextualization of the Hypercubic competitive finding; the implication for the methodology-over-capability positioning thesis; the timing-window recognition (methodology positioning available to establish now, not indefinitely); and the integration-with-Claude-Code framing as a strength rather than a dependency. This investigation should produce structural-defensibility-positioning v0.2, retaining v0.1 as superseded.
Both companion investigations are filed as named follow-on, not produced here, in part to preserve the scoping discipline (scoping in current chat, drafting in fresh chat) and in part because each merits its own depth.
The investigation declines several adjacent moves and names them explicitly.
It does not update queued directions v0.14. The Operator decision named in the plain-language summary is whether to elevate the external render specialists deferred work using this investigation's findings; the elevation itself is a separate CR amendment.
It does not propose a Phase for execution. The two-stage render pipeline of §5 would land as a multi-Phase build — at minimum the materialization specialist, then the Claude-Code integration spike — but Phase scoping is not done here.
It does not address the Operator-authority surface for /goal runs in production engagements. There are real questions about whether the /goal mechanism's autonomous-iteration property fits cleanly with Loomworks's always-require-approval-at-alpha posture. The likely resolution is that /goal runs are dispatched only after Operator approval of the materialized test suite, but the discipline question deserves its own treatment.
It does not address security and privacy posture for engagements where rendered code touches sensitive data. Claude Code's auto-mode and /goal running together imply the Operator has approved a posture of "execute commands without per-turn approval"; for regulated engagements (federal SBIR work, healthcare, finance) this posture may need explicit gating that the investigation does not specify.
It does not address the cross-vendor portability claim from §7 in detail. The claim is that the Loomworks materialization specialist would be portable across /goal implementations from different vendors. The claim is plausible — the /goal interface is converging — but is not stress-tested against actual vendor-specific differences in this investigation.
It does not address render-room specialists for non-code outputs (document rendering, presentation rendering, image rendering, slide-deck rendering). The two-stage pipeline of §5 is specifically for the code-from-spec class. Other render-specialist classes are out of scope.
This investigation depends on and extends the following Loomworks documents:
If this investigation produces follow-on action, the most likely sequence is: (a) Operator decision on elevation of external render specialists from deferred to active in queued directions v0.15; (b) materialization-specialist investigation in a fresh session; (c) structural-defensibility positioning v0.2 in a fresh session; (d) Phase scoping for build of materialization specialist and Claude-Code integration spike.
The investigation moved through several framings that were considered and corrected. The Discovery-record discipline asks that these be named alongside what landed.
The first framing considered: that /goal is itself the Render room of Loomworks methodology. As I started reasoning about the Operator's question, the surface reading was that Claude Code's /goal is structurally identical to a Render room, and therefore Loomworks could simply adopt /goal as its Render-room substrate. The correction was that /goal is one specialist class (code-from-shape-as-specification) for one slot in the Render room, not the whole Render room. The Render room has many specialist classes (document, presentation, code, image, slide-deck) and the methodology already specifies the boundary specialists attach at. The methodology-as-Render-room-host versus /goal-as-Render-room framing would have collapsed the architecture; the methodology-as-host with /goal as one attached specialist preserves it.
The second framing considered: that the /goal convergence makes external render specialists redundant — that Loomworks should stay scoped purely to specification work and let the user invoke /goal themselves. The correction was that the queued-directions item is external render specialists — meaning specialists that Loomworks integrates into its Render room while attaching to external capability layers. The convergence does not eliminate the integration work; it makes the integration target more specific and more available. Staying scoped to specification work alone would forfeit the end-to-end story that turns out to be load-bearing for both proposal narratives (§9) and Operator confidence in the platform.
The third framing considered: that the REQ-spec can be piped directly into /goal as the condition string. I had to walk myself off this one carefully. The Operator's question phrasing — "if the REQ spec is directed to produce an app using Claude Code" — invited the direct-pipe reading. The correction came from the three gaps in §4: the 4,000-character cap, the transcript-observability constraint, the long-running drift risk. The direct-pipe framing would have produced a brittle implementation that failed on any non-trivial REQ-spec; the two-stage pipeline framing produces a resilient implementation. The materialization step is load-bearing.
The fourth framing considered: that the shape→render→close pattern in Loomworks is a derived pattern from the /goal pattern, since /goal shipped first as a developer-tool feature. The correction was that the Loomworks methodology developed this pattern independently before /goal existed (the four-room pipeline is named throughout Loomworks's methodology documents v0.6 through v0.20, predating Claude Code v2.1.139 by months). The convergence is two parallel attempts to specify the same architectural primitive; the direction of derivation is not from /goal to Loomworks but from a shared underlying architectural recognition to both /goal and Loomworks's methodology. This matters for positioning: the convergence is validation, not borrowing.
The fifth framing considered: that the cross-vendor /goal convergence is a competitive threat to Loomworks (other vendors are building toward the same architectural primitive). The correction was that the convergence is on the primitive, not on the methodology that makes the primitive produce correct end-states. Vendor capability is converging; methodology positioning is not. The Operator's standing recognition — that as builders get more capable, the specification layer becomes the leverage layer — is strengthened by the convergence, not threatened by it. The threat framing would have produced defensive positioning; the validation framing produces offensive positioning with timing urgency (§8's closing recognition about the window being open now but not indefinitely).
The sixth framing considered: that the materialization specialist is a small implementation detail rather than a load-bearing component. The correction came from working through §4's three gaps: the materialization specialist closes all three gaps; without it, the integration is fragile; with it, the integration is portable across /goal implementations. The implementation-detail framing would have undersized the engineering effort and the strategic importance; the load-bearing-component framing produces the companion-investigation disposition in §10 and the Phase-scoping implication in §11.
The seventh framing considered: that this investigation should also produce the materialization-specialist design and the structural-defensibility v0.2. The correction was the scoping discipline: scoping in current chat, drafting in fresh chat. Each of those two artifacts merits its own session for depth-and-trajectory; combining them with the present investigation would have produced a thicker single document with weaker per-thread development. The named-but-deferred disposition in §10 honors the discipline.
/goal mechanics, REQ-spec alignment, the two-stage render pipeline pattern, the architectural placement as one external render specialist, and the industry-convergence-as-methodology-validation recognition. Names two companion investigations (materialization-specialist design, structural-defensibility v0.2 update) for follow-on sessions. Preserves seven framings considered and corrected during the investigation.End of investigation v0.1.