Launchfiles

Agent operating contract

V0 documentation · no live execution

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.

Launchfiles agent scope model
ScopeAgent mayAgent may notRequired proofBlocked behavior
readInspect 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.
proposeDraft 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_approvalPerform 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.

decision

Exact choice, authority, rationale/why now, status, and proof.

work_order

Owner, scope, approval boundary, forbidden actions, status/blocker, required proof.

run_ledger

Did execution happen, terminal result, side effects, receipt/artifacts.

gate_result

Gate ID, outcome, severity, reason, repair/proof.

approval

Approver, exact action/scope, artifact hash, time/expiry.

readout

Window, source, observed result or explicit missing result, recommendation.

memory_update

Proposed 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.

  1. V0

    Read approved context

    Agents consume the operating file, doctrine refs, and deterministic exports like the example below.

  2. Next

    Propose signals, decisions, and work orders

    Draft bounded objects for founder review without treating proposals as approved truth.

  3. Later

    Execute-with-approval tools

    Run only the exact approved action with idempotency keys, expected side effects, and rollback rules.

  4. 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.