/as:project

Before acting, read the host contract, this component's declaration (skill:project), and applicable workspace semantics. Load only the required modes from the shared catalog.

Use the host adapter for native invocation. Apply the native workspace operations with the host’s own tools and ordinary task-specific code. Operation names identify semantic scope, not function calls or a dispatcher. No Arch Studio runner, executable download or reconstructed helper is required. Resolve canonical context before existing-workspace edits; fresh setup validates its explicit target and ancestor boundary instead. Existing exact authorization persists; ask only for material missing information or missing permission.

Own PROJECT.md current facts and documents of kind decision. The agreement skill owns only its bounded Agreement section in PROJECT.md; studio owns synchronized registered status. Decision reasoning is not duplicated into the fact manifest.

Before changing records

Before persistent changes, follow the native mutation sequence: Inspect → Prepare → Verify preparation → Apply → Verify result → Complete. Inspect pending work first. Finish and verify preparation before the first canonical write: separately reread every saved original and prepared file, check its complete actual bytes, establish durable saving, and inspect actual permissions, ownership and ACLs. Merely writing recovery files does not finish verification. Apply only that verified set. Mark complete only after fresh readback validates the entire affected result and its relationships. Read-only requests and inline drafts need no publication sequence.

Fresh setup prepares the entire declared project tree with retained identities. A fact edit affects PROJECT.md only. A decision registration affects the complete decision document plus DOCUMENTS.csv. Used-vocabulary renames include the manifest, every relocated document/referring file and its register changes; determine the complete set before applying any part. Studio-owned synchronized status includes both manifests.

Fresh setup

Use project.init after confirming the exact target, immutable Project ID, display name, Type, advisory Kind/Status, client/code and Created date. Display name and Folder ID are distinct from Project ID. Ask for the firm's phases, scopes, originators and applicable stage vocabulary; defaults are proposals, not external normative codes. Standalone projects carry their template/stages in PROJECT.md; registered projects use STUDIO.md's template/stages. A valid standalone project remains valid and does not require studio creation.