Context
T0.2 gate of the #13349 horizon map. The shipped mechanism chain (#13357 request intake → #13362/#13363 first grid via NL → #13361 follow-up mutation) proved the path under proof-scaffold constraints. The keeper flow makes it a PRODUCT surface — the safety contract needs re-validation and a recorded v2 before T1–T3 leaves consume it.
The Problem
The epic's own rejected trap ("arbitrary code generation as the first path") is only as strong as the blueprint constraint's current shape. Questions the v2 record must answer: which component types are blueprint-emittable in the keeper flow (the T5 plugin contract's floor); what the schema validates (structure, config allowlist, no function-valued configs, no raw HTML per #13018); where validation runs (agent-side emit + harness-side accept — fail-closed on both); what a rejected blueprint renders as (honest refusal state, T1.5); and how follow-up mutations (#13361's mechanism) are bounded by the same contract.
The Fix
A v2 contract record: the blueprint JSON-schema (or validator module) location, the emit/accept validation split, the refusal rendering contract, and the mutation-boundary clause — with a falsifying test naming an attack-shaped blueprint (function config / HTML injection / unknown ntype) that must be refused on both sides.
Acceptance Criteria
Out of Scope
The T5 plugin contract (breadth); persistence/write-through (T4); the UI.
Related
Parent: #13349 (T0.2). #13357 · #13361 · #13018 · #13012 (no-privileged-chrome — the same contract protects the harness's own views).
Live latest-open sweep: latest 8 checked 2026-07-04T03:32Z, no equivalent.
Origin Session ID: a5af7cf6-45a3-42db-8a30-f04f4241a55c
Retrieval Hint: "constrained blueprint safety contract v2 keeper flow emit accept validation"
Context
T0.2 gate of the #13349 horizon map. The shipped mechanism chain (#13357 request intake → #13362/#13363 first grid via NL → #13361 follow-up mutation) proved the path under proof-scaffold constraints. The keeper flow makes it a PRODUCT surface — the safety contract needs re-validation and a recorded v2 before T1–T3 leaves consume it.
The Problem
The epic's own rejected trap ("arbitrary code generation as the first path") is only as strong as the blueprint constraint's current shape. Questions the v2 record must answer: which component types are blueprint-emittable in the keeper flow (the T5 plugin contract's floor); what the schema validates (structure, config allowlist, no function-valued configs, no raw HTML per #13018); where validation runs (agent-side emit + harness-side accept — fail-closed on both); what a rejected blueprint renders as (honest refusal state, T1.5); and how follow-up mutations (#13361's mechanism) are bounded by the same contract.
The Fix
A v2 contract record: the blueprint JSON-schema (or validator module) location, the emit/accept validation split, the refusal rendering contract, and the mutation-boundary clause — with a falsifying test naming an attack-shaped blueprint (function config / HTML injection / unknown ntype) that must be refused on both sides.
Acceptance Criteria
Out of Scope
The T5 plugin contract (breadth); persistence/write-through (T4); the UI.
Related
Parent: #13349 (T0.2). #13357 · #13361 · #13018 · #13012 (no-privileged-chrome — the same contract protects the harness's own views).
Live latest-open sweep: latest 8 checked 2026-07-04T03:32Z, no equivalent.
Origin Session ID: a5af7cf6-45a3-42db-8a30-f04f4241a55c Retrieval Hint: "constrained blueprint safety contract v2 keeper flow emit accept validation"