C1+C2: required-caps report + governed profile

[howlcipher]

What landed

• C1 (P0.5) required-capabilities report: bytecode.RequiredCapabilities = union of opcode capabilities + store-URI requirements + lazy CALL (conservatively reports all capabilities because generated code executes). Deterministic, compact JSON, no execution.
• C2 (P0.3) governed profile v0: named construct allow-list. governed rejects lazy_synthesize, ephemeral_circuit, neural_circuit, achieve, confidence, llm_generate, exec, spawn, db_connect/sql_query, include outside root, and Go/JS targets with stable code PROFILE_FORBIDDEN_CONSTRUCT, before any output is written. Checked pre- and post-include expansion.

CLI surface

• howlframe inspect --caps <artifact.hfbc>
• howlframe -required-caps <artifact>
• howlframe check --profile=default|governed <src.howl>
• howlframe build --profile=default|governed [--target=...] <src.howl>
• Default profile = unchanged behavior.

Tests

• internal/bytecode: RequiredCapabilities rules
• internal/construct: profile tables + seven-site AST scan
• internal/hfir: profile diagnostics / drift
• internal/vm: source conformance + hermetic execution soundness (incl. lazy generated effects)
• root: TestCLIRequiredCapsAndGoverned, TestRequiredCapsFixtureSoundness
• gofmt -l . empty, go vet ./... clean, go test ./... -count=1 all green locally (incl. difftest, gogen, javascript, vm).

Hard nos (respected)

• No production HFIR flip: -compile-bc stays AST bytecode; Write flagged http_server bytecode and stop #90 stays Partial
• No HFBC wire/format change
• No C4/C5/harness, no DOM work

Deferred

• Legacy -profile flag support (only check|build --profile for now)

Sandbox notes

An earlier Codex run hit sandbox-only failures (httptest listen EPERM, JS exec EPERM, difftest); in the final local run the full suite passed.

Journal: docs/journals/2026-10-05_c1_c2_required_caps_governed_profile.md

[howlcipher]

Motoko COMMENT on head b7090de3eed7d0fdd0dcf26ea168e2da36b63a27 (base c6c7275d).

Verdict: merge-ready (CI build green). Diff matches claimed C1+C2 scope.

Checked

• C1: bytecode.RequiredCapabilities is a deterministic, non-executing over-approx: opcode Registry caps ∪ store-URI requirements on STORE_OPEN ∪ all caps for lazy/unknown CALL. Sorted output. CLI: inspect --caps and -required-caps.
• C2: governed allow-list rejects claimed constructs (plus spawn_agent), outside-root include/use, and Go/JS targets with PROFILE_FORBIDDEN_CONSTRUCT via hfir.VerifyProfile pre- and post-expansion, before any write. Default profile short-circuits unchanged.
• Hard nos intact: -compile-bc still runHFIRGate → bytecode.CompileToBytecode (no prod HFIR flip); #90 Partial; no tip-lock retake; no DOM; no HFBC wire/opcode change (HFBCFormatVersion still "1"); no C4/C5/harness.
• Tests cover unit caps/profile, seven-site VM conformance, hermetic execution incl. lazy synthesized FS write, CLI rejection-before-write, corpus soundness under exact grant.

Non-blockers

• Legacy bare -profile still deferred (only check|build --profile) — as documented.
• “Seven-site AST scan” wording is slightly off: seven sites live in VM conformance for requireCapability; construct side is profile table + ScanProfile.
• Caps report is program-wide conservative union, not path-sensitive (acknowledged).

Draft left draft. Okabe: undraft + squash-merge when ready.