RFC-0006: Computed Frontmatter Fields (Layer 4)

[mrangelmarino]

Summary

RFC-0001 §6 puts directives in the body — there is no defined mechanism for directives that produce structured frontmatter values. RFC-0006 proposes Layer 4: a !spec YAML local tag that marks a frontmatter scalar as computed at transformation time, evaluated by the same AI runtime that interprets Layer 3 directives.

⚠️ DRAFT — not ready for review. This PR scaffolds the RFC and surfaces the open authorial / design judgment calls as [ANGEL: REVIEW] markers throughout. It also includes a foregrounded §0 Design Concerns section that questions whether this RFC should land as drafted at all. Resolve the §0 concerns before flipping from draft to ready.

Why §0 exists

The most consequential [ANGEL: REVIEW] calls aren't syntax bikeshedding — they're whether this RFC should exist now. §0 names them up front so they can't be smuggled in by silence:

• §0.1 Sequencing. RFC-0001 §12 reserves slots 0002–0005 for Schema Format, Directive Stdlib, Composition, Versioning. Layer 4 jumps the line and depends on RFC-0002 in non-trivial ways (§4.1, §3.6).
• §0.2 Three examples want three solutions. title_plain is a regex. read_time is arithmetic. asserts is a DSL. A single !spec-only mechanism collapses distinctions that may matter; a multi-resolver shape (!spec/!fn/!expr) is the alternative.
• §0.3 No reference implementation exists. Spec'ing L4 before any runtime ships L1 risks over-specification.
• §0.4 Frontmatter-can-read-secrets. Computed-field directives have read access to other frontmatter values, including any embedded secrets — a real expansion of the RFC-0001 §9 attack surface.

[ANGEL: REVIEW] markers

16 markers in the document. Highest-leverage ones:

Section	Line	Decision
§0 preamble	20	Whether §0 should exist or be removed before flipping to ready
§0.1	30	Sequencing: proceed now, or reorder after RFC-0002
§0.2	44	Single-resolver (!spec only) vs multi-resolver
§0.3	50	Add Status: Draft (pre-implementation) and gate promotion on a runtime
§0.4	58	Acceptable risk vs require explicit expose: allowlist
§3.1	128	Tag name (!spec vs !compute/!derive/!ai)
§3.5	179	Top-down evaluation vs DAG resolution
§3.7	214	Sentinel shape (in-place object vs typed-null + report)
§4.1	229	Layer 1 interaction depends on RFC-0002; defer or forward-reference
§4.3	247	L4 sees pre-L3 input (current) vs post-L3 output
§6	298	Reserved metadata: ship all five keys or only directive+cache
§7.2	320	"Independent of L3" claim — true but practically misleading
§8.3	377	Whether asserts belongs in L4 at all
§9	385	Per-RFC implementation notes vs single repo-level tracker
§10.2	413	L4 tool access: denied-by-default vs read-only-by-default

Full list with line numbers via grep -n "ANGEL: REVIEW" rfc-0006.md.

Verification

• rfc-0006.md exists at repo root alongside rfc-0001.md
• All 12 required sections present (Header, Abstract, Motivation, Terminology, Spec, Layer Interactions, Pipeline, Reserved Metadata, Conformance, Security, Reference Implementation, Future Work) plus the inserted §0 Design Concerns
• 16 [ANGEL: REVIEW] markers (well above the ≥3 threshold)
• rfc-0001.md not modified
• PR opened as DRAFT — not ready for review

Test plan

• Read §0 first; decide whether the four design concerns are blockers
• Walk markers in order; resolve or convert to followup issues
• If §0.1 is decided "reorder," close this PR rather than flipping to ready
• If §0.2 is decided "multi-resolver," substantially rewrite §3 before flipping to ready
• If proceeding as-is: remove §0, remove all [ANGEL: REVIEW] blocks, flip from Draft → Ready

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
specscript	Ready	Preview, Comment	May 1, 2026 5:22am