Agent operating contract
Read one context. Stay in scope. Return receipts.
Agents consume approved launchfile exports, propose bounded work for founder review, and execute only inside explicit approval. Every claim needs a durable receipt.
Answer first
What agents may do
Read approved context. Propose bounded signals, decisions, and work orders. Execute only inside an explicitly approved scope.
Completed work requires a durable receipt — run ID, actor, scope, inputs, outputs, gate results, artifact links, side-effect status, and terminal state. A plan, tool call, or model response is not execution.
Core command test
Before editing any product surface, read the current operating file and pass this check.
Cursor, read Launchfiles before editing.
An agent passes only when it can identify:
- Current approved decision
- Exact work order
- Allowed scope
- Forbidden actions
- Approval boundary
- Required proof
- Latest receipt or explicit not_run
- Unresolved gates
- Launchfiles vs Content OS boundary
Scope model
Three scopes govern every agent interaction. Proposals and plans never cross into execution without a separate approval and receipt.
| Scope | Agent may | Agent may not | Required proof | Blocked behavior |
|---|---|---|---|---|
read | Inspect approved context, doctrine refs, decisions, work orders, receipts, gates, readouts, and approved memory. | Change state, claim execution, or treat proposals as approvals. | Source mode label, object IDs, and approval boundary remain visible. | Inferring execution from plans, tool calls, or model output. |
propose | Draft signals, decisions, work orders, or memory updates for founder review. | Treat a proposal as approved truth, expand scope, or publish. | Proposal labeled proposed; supersession and cooldown when applicable. | Auto-approving or mutating production systems. |
execute_with_approval | Perform the exact approved action inside the granted scope and return proof. | Expand scope, publish, mutate unrelated systems, or skip the receipt. | Durable run ledger with terminal state and side-effect truth. | Unrestricted autonomous execution. |
Object rendering law
Every launchfile object must expose exact state in the interface. Missing proof stays missing; proposals are not approvals.
decisionExact choice, authority, rationale/why now, status, and proof.
work_orderOwner, scope, approval boundary, forbidden actions, status/blocker, required proof.
run_ledgerDid execution happen, terminal result, side effects, receipt/artifacts.
gate_resultGate ID, outcome, severity, reason, repair/proof.
approvalApprover, exact action/scope, artifact hash, time/expiry.
readoutWindow, source, observed result or explicit missing result, recommendation.
memory_updateProposed lesson, sources, confidence, approval state/supersession.
Receipt requirement
No agent execution is complete without a durable receipt adjacent to the claim it supports.
- run_id
- Durable workflow or agent run identifier.
- actor
- Human, agent, or workflow actor that initiated the run.
- scope
- Exact approved product, paths, and systems.
- inputs
- Commands, artifacts, and hashes consumed.
- outputs
- Artifacts written and verification results.
- gate_results
- Deterministic or judgment gates that permitted or blocked progression.
- artifact_links
- Paths or URLs to durable proof objects.
- side_effect_status
- Whether publish, queue, schedule, or public mutation occurred.
- terminal_state
- completed, blocked, failed, or not_run — never inferred.
A model response, tool call, or green status is not a receipt.
Deterministic agent context example
Fixture export only — secret-free, scoped, no mutable runtime state, no unrestricted execution language. Product-repo agents consume approved exports; they do not browse private orchestration source.
Agent export
launchfile_agent_export_v0{
"schemaVersion": "launchfile_agent_export_v0",
"generatedAt": "2026-06-19T19:15:00+07:00",
"sourceMode": "fixture",
"scope": {
"workspaceId": "workspace_launchfile_fixture",
"productId": "product_launchfile_fixture"
},
"currentApprovedDecision": {
"id": "decision_visual_direction_v2",
"title": "Use the Verified Operating File visual direction",
"decision": "Adopt the supplied Launchfile brand board as the V0 visual source for page and component protocol work.",
"rationale": [
"The file-first mark and restrained palette express operating-file, verified, controlled, and forward principles.",
"The selected direction removes the previous visual-source blocker without authorizing production behavior."
],
"authority": "fixture_founder"
},
"workOrder": {
"id": "work_order_frontend_protocol_v2",
"objective": "Make future Launchfile pages contract-led, visually coherent, proof-oriented, responsive, and agent-readable.",
"owner": "fixture_codex",
"allowedPaths": [
"docs/LAUNCHFILE_*.md",
"docs/page-contracts/**",
"apps/launchfile-web/**",
"__tests__/launchfile/**"
],
"allowedSystems": [
"local filesystem",
"local app",
"local browser",
"local tests"
],
"acceptanceCriteria": [
"No route exists without a Page Contract.",
"The Today route exposes fixture mode, blockers, proof, and not_run truth.",
"The component demo shows all ten approved primitives.",
"Typecheck, focused tests, build, and visual QA pass."
],
"forbiddenActions": [
"Deploy or provision infrastructure.",
"Mutate a database or production system.",
"Wire approval, execution, publishing, or Content OS runtime behavior.",
"Rename Content OS runtime identifiers."
],
"requiredProof": [
"Launchfile app typecheck passes.",
"Focused Launchfile tests pass.",
"Launchfile production build passes.",
"Desktop and mobile screenshots pass visual QA."
]
},
"doctrineRefs": [
"AGENTS.md",
"docs/LAUNCHFILE_PAGE_CREATION_PROTOCOL_V0.md",
"docs/LAUNCHFILE_UI_COMPONENT_SPEC_V0.md",
"docs/LAUNCHFILE_VISUAL_QA_SCORECARD_V0.md"
],
"executionAuthority": {
"mode": "execute_with_approval",
"approvalId": "approval_visual_direction_v2",
"allowedActions": [
"Edit approved local docs and fixture UI files",
"Run local verification and visual QA"
]
},
"executionTruth": {
"state": "not_run",
"reason": "This fixture contains no workflow run ledger; local UI work is not runtime execution proof.",
"latestReceipt": null
},
"unresolvedGates": [
{
"id": "gate_behavior_wiring_v2",
"gateId": "BLOCK_BEHAVIOR_WIRING",
"outcome": "fail",
"severity": "blocking",
"reason": "No separate product approval, authorization model, idempotency contract, or receipt-producing mutation path exists."
}
]
}Integration path
Progressive maturity from read-only context to scoped execution tools.
V0
Read approved context
Agents consume the operating file, doctrine refs, and deterministic exports like the example below.
Next
Propose signals, decisions, and work orders
Draft bounded objects for founder review without treating proposals as approved truth.
Later
Execute-with-approval tools
Run only the exact approved action with idempotency keys, expected side effects, and rollback rules.
Future
MCP resources and tools
Expose read/propose/execute surfaces after scopes, receipts, idempotency, and rollback are explicit.
Launchfiles / Content OS boundary
Launchfiles
The master operating file and founder/agent product surface across decisions, scoped work, proof, readouts, and memory.
Content OS
The content-specific module for evidence, strategy, generation, quality gates, review, and content readouts. Internal commands and audit paths are not public naming guidance.
Repository agents
Engineering agents opened in this repository may patch Launchfiles product code. Product-repo agents consume exported artifacts and approved execution packets only.
No mimicry
Agents do not browse or mimic private orchestration source unless explicitly opened in the repo. Content OS can generate and evaluate page packets; it is not the public master brand.