Content Production System is a file-driven operating system for launch narrative, demo planning, content workflows, expert routing, and governed evidence. It starts from a route-context fixture so the project has route-context, memory, protocol, expert, evidence, and Aming Claw governance boundaries before product-specific code is added.

• system-fixture/ contains the instantiated route-context baseline.
• system-fixture/map/system-map.json defines domains, files, dependencies, and graph reconcile hooks.
• system-fixture/route-context/ owns visible route context and action policy.
• system-fixture/protocols/ defines starter file-backed protocols.
• system-fixture/experts/ defines routed expert lanes for content work.
• system-fixture/memory/ defines private feedback and lesson boundaries.
• system-fixture/evidence/ defines dispatch, merge, and close evidence gates.
• system-fixture/governance/ binds this system to Aming Claw backlog, graph, timeline, and close gates.
• content-system/ defines the first content production video demo contract: brief, storyboard, shot list, and reproducible capture/render pipeline.

The first governed content artifact is a technical product demo for the content production system itself. The demo shows how a fuzzy video goal becomes an expert-routed content plan, then a backlog-backed production contract with evidence checkpoints.

Core artifacts:

• content-system/demo-brief.md: audience, claim, duration, route evidence, and done definition.
• content-system/storyboard.md: scene-by-scene story with evidence checkpoints.
• content-system/shot-list.md: recording plan for each visible capture.
• content-system/render-pipeline.md: reproducible capture, narration, caption, assembly, and verification flow.
• content-system/test-scenarios/: executable scenario contract and current satisfaction/toolchain reports for media E2E readiness.
• content-system/video-request-workflow.json: public machine contract for the user-facing video request queue, folder import, asset inbox, brief revisions, preview approval, rendering, and publishing states.
• content-system/video-request-page.html: static first-pass intake page for ordinary users to choose recordings, enter requirements, revise briefs, and export a request manifest.
• content-system/capture-plan.md, content-system/narration-script.md, and content-system/captions/: source-controlled inputs for future CLI capture, voice, caption, and render automation.

The primary operator path is a simple page: choose screen recordings, audio, images, or reference text; enter the video goal; revise the brief; then export a public-safe request manifest. The advanced path is folder import for CLI or batch work:

video-request/
  request.json
  brief.md
  assets/
    manifest.json
  references/
  output/

Both paths map to the same Video Request Queue states:

Draft -> Assets Ready -> Brief Ready -> Plan Ready -> Preview Ready
-> Approved -> Rendered -> Published

Revisions never overwrite the original request. They create brief revision records with changed fields, affected scenes/assets, and rerender scope. Backlog semantics stay content-domain-specific: ordinary users see request status, next action, missing assets, and review notes; internal route hashes and close-gate evidence remain implementation evidence.

Run:

python -m unittest discover -s tests

The tests confirm every JSON config parses, all manifest paths exist, route context exposes visible alerts and role policy, and the governance, expert, memory, and evidence layers are present.

Recommended project id: content-sys

Reviewed bootstrap excludes:

• .git
• .pytest_cache
• __pycache__
• node_modules
• dist
• build
• .expo
• .next
• coverage