chore(internal#33): template_assets is now consumed by the CP (sync contract SSOT) #3107
Reference in New Issue
Block a user
Delete Branch "chore/internal-33-template-assets-consumed"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sync the producer copy of
provision_request.contract.jsonwith the control-plane SSOT for internal#33.template_assetsflipscp_consumesfalse -> true: the CP now decodes the field and routes it to aWorkspaceTemplateAssetProvisionerbackend (EC2 + LocalDocker) that materializes the concierge persona as/configs/system-prompt.md. Previously a DEAD WIRE FIELD that left SaaS concierges booting identity-less on create AND restart (RFC #2843 #24 / project_saas_restart_re_stub_config).Doc-only; keeps the two repos' contract copies byte-identical. The producer pin test (cpProvisionRequest tags == fields keys) is unaffected and passes.
Pairs with controlplane PR #879 (the actual consumer + EC2 backend).
Generated with Claude Code.
APPROVE on current head
4c182d0b.5-axis review:
5-axis review on current head
4c182d0b:Correctness: APPROVE. The diff is limited to
workspace-server/internal/provisioner/provision_request.contract.json;template_assets.cp_consumesis nowtrueand the note accurately records the internal#33/CP consumption path for template assets.Security: no runtime behavior, auth, tenant, or secret-handling code changes; this is contract metadata only.
Tests/CI: JSON parses cleanly. CI has one required-context failure,
E2E Staging Concierge Creates Workspace, but its log is not caused by this data-only diff: CP health preflight passed, the tenant reachedrunning, and the failure wasTenant /health never 2xx within 15m, matching the staging/tenant-readiness RCA I filed on core#3104 comment 107578.Scope: one contract file changed; no unrelated churn.
Docs/readability: the updated note is explicit about the consumer and previous dropped-field state.
Verdict: APPROVED. The required E2E failure should be routed as the known staging provisioning/readiness issue, not as a #3107 code blocker.