What the Project OS contains, how incremental exports work, and safe overwrite rules.
10xs/ folder — safe to extract into any repoworkflow/ and architecture/local/ are yours — never overwritten10xs/MERGE_GUIDE.md after downloading for re-import instructions10xs/ ├── CLAUDE.md — AI governance adapter ├── PRD.md — Project requirements ├── README.md — Onboarding guide ├── MERGE_GUIDE.md — Re-import instructions ├── VERIFICATION_CHECKLIST.md — Integrity manifest ├── architecture/ │ ├── generated/ — Blueprint, decomposition, status │ │ ├── BLUEPRINT.json │ │ ├── DECOMPOSITION.json — When execution plan exists │ │ └── EXPORT_STATUS.json — Completeness metadata │ └── local/ — Your architecture decisions ├── governance/ — Profile, kernel version, schemas │ ├── GOVERNANCE_PROFILE.yaml │ ├── KERNEL_VERSION.json │ └── SCHEMAS/ │ ├── execution_contract_schema.json │ └── reporting_schema.json ├── doctrine/ — Role definitions, workflow, quality gates │ ├── ROLE_ARCHITECT.md │ ├── ROLE_CODING_ASSISTANT.md │ ├── TASK_WORKFLOW.md │ ├── SESSION_CONTINUITY.md │ ├── QA_VALIDATION.md │ └── CLEAN_ARCHITECTURE.md └── workflow/ — Your execution artifacts
The Project OS is a portable, self-contained governance instance generated for your project. It contains your PRD, architecture blueprint, execution plan, governance rules, and AI adapter — everything an AI assistant needs to follow structured delivery standards. It is Layer 3 of the 10xs architecture.
The export produces a 10xs/ folder. See the folder tree above for the full structure. Key files:
CLAUDE.md — AI governance adapterPRD.md — Your project requirementsREADME.md — Onboarding guideMERGE_GUIDE.md — Safe re-import instructionsVERIFICATION_CHECKLIST.md — Integrity manifestarchitecture/generated/ — Blueprint, decomposition, export statusgovernance/ — Governance profile, kernel version, JSON schemasdoctrine/ — Role definitions, workflow standards, quality gatesThe Project OS does not contain:
It governs how your team works, not what you build.
Anywhere in your repository. The CLAUDE.md adapter uses relative paths to reference doctrine and architecture files.
my-project/10xs/ — Repository root (recommended)my-project/governance/10xs/ — Subdirectorypackages/my-app/10xs/ — MonorepoThe only requirement is that 10xs/CLAUDE.md can resolve paths relative to the 10xs/ folder.
Three steps:
10xs/ folder in your repo root10xs/CLAUDE.md to your project root — Claude Code reads CLAUDE.md automatically from the project rootClaude Code reads CLAUDE.md from the project root on every session start. The adapter references doctrine documents inside 10xs/, so your assistant discovers and follows governance rules without any manual prompting.
Each export is a point-in-time snapshot. The export engine reads your current PRD, blueprint, and execution plan, assembles governance artifacts, and generates a zip file client-side.
No data is stored server-side after generation. The zip contains only the 10xs/ folder — extract it into your repo root or any directory. No files outside 10xs/ are created or modified.
Yes. Incremental exports are supported.
Safe to overwrite (machine-managed)
10xs/architecture/generated/10xs/governance/10xs/CLAUDE.md, 10xs/PRD.md, 10xs/README.mdNever overwrite (user-managed)
10xs/workflow/ — Your execution artifacts, session notes, reports10xs/architecture/local/ — Your local architecture decisionsSee 10xs/MERGE_GUIDE.md in your export for the complete guide.
When you export before fully decomposing all stories:
The EXPORT_STATUS.json file records completeness: totalStories, storiesWithMicrotasks, and exportType ("complete", "partial", or "story-level-only").
You can return to the Decompose page, generate remaining microtasks, and re-export.
Every export includes 10xs/governance/KERNEL_VERSION.json with three version fields:
Plus a governanceHash — a fingerprint of the resolved governance rules. If the kernel version matches your current export, doctrine files are unchanged and do not need updating.
Every export includes 10xs/governance/KERNEL_VERSION.json with a governanceHash — a fingerprint of the resolved rules.
When you re-export:
MERGE_GUIDE.md for safe overwrite pathsYour work artifacts (10xs/workflow/) and local decisions (10xs/architecture/local/) are never overwritten regardless of kernel version changes.
10xs/doctrine/ contains six governance documents:
ROLE_ARCHITECT.md — Architect role definition and authorityROLE_CODING_ASSISTANT.md — Coding assistant expectations and quality gatesTASK_WORKFLOW.md — Task decomposition and completion protocolSESSION_CONTINUITY.md — Handoff and context preservation rulesQA_VALIDATION.md — Validation and evidence requirementsCLEAN_ARCHITECTURE.md — Code quality and file size standardsThese files are version-pinned to the kernel. Your AI assistant reads them via the CLAUDE.md adapter.
The governance profile (10xs/governance/GOVERNANCE_PROFILE.yaml) defines the constraints your AI assistant must follow when breaking work into microtasks:
minHours / maxHours — time budget per taskmaxFiles — maximum implementation files per taskmaxDependencies — dependency limit per taskenforcementMode — warn (advisory) or block (hard stop)These constraints prevent scope creep and keep each task small, reviewable, and auditable.
An execution contract formally binds a task to governance constraints before work begins. It captures the task scope, file budget, time estimate, and dependencies — then locks them with a SHA-256 hash.
When the task completes, a validation engine evaluates the work against the contract. Same inputs always produce identical outputs — no randomness.
This creates an auditable paper trail: what was planned, what was delivered, and whether governance constraints were met.
The validation engine evaluates completed work against its execution contract. It checks file counts, time spent, and constraint compliance, then produces a result:
The enforcement mode in your governance profile controls whether violations produce warnings or hard blocks.
The 10xs/workflow/ directory is your project's work history. It is user-managed and never overwritten on re-export:
workflow/session_handoffs/ — context for each work sessionworkflow/task_reports/ — completion reports with evidenceworkflow/execution_contracts/ — formal task bindingsThis gives you a complete audit trail of what was planned, delivered, and validated — entirely within your repository.
The export includes a CLAUDE.md adapter optimized for Claude-based tools. However, the governance engine is LLM-agnostic.
The README.md in your export includes a compatibility table for other tools (Cursor, Windsurf, Copilot, Cline) with setup instructions for each.
The CLAUDE.md file lives at your project root (copied from 10xs/CLAUDE.md during setup). It is the project-specific binding between kernel doctrine and Claude Code. You can edit it to add your own rules. Common customizations:
10xs/ in a subdirectoryKeep the adapter concise (under 200 lines). It should reference doctrine documents, not duplicate them.
No special prompting is needed. The workflow is:
10xs/CLAUDE.md to your project root (Claude Code reads it automatically)10xs/doctrine/ — your assistant discovers governance rules on its ownNo prompt engineering required. Claude Code loads CLAUDE.md from the project root at every session start. The governance engine handles the rest — constraints, evidence requirements, and role definitions are all embedded in the doctrine that the adapter points to.
Yes. The governance engine is LLM-agnostic. The export includes a CLAUDE.md adapter optimized for Claude, but the doctrine works with any AI coding tool:
.cursorrules.windsurfrulesSee the README.md in your export for tool-specific setup instructions and the full compatibility table.
Yes, at two levels:
enforcementMode, file limits, or time budgets in the profile10xs/architecture/local/ (never overwritten on re-export)Doctrine documents (10xs/doctrine/) are kernel-managed and version-pinned. Editing them directly is not recommended — your changes would be overwritten on the next export.