project · diff

git:20260812.ab1329f to git:20260920.ef0a19e

20 added, 91 removed. Audit A to A.

---
name: project
- description: Create or maintain an Architecture Studio project — initialize its record bundle, remember sourced facts, capture or supersede decisions, inspect project status, or migrate a 1.x PROJECT.md. Use when the user says “set up the project,” “remember this,” “we decided,” asks about project context, or runs /as:project.
+ description: "Initialize or inspect a project, maintain sourced current facts and record durable decisions. Use for project context or remember-this requests; other record types retain their owners."
allowed-tools:
- Read
- Write
- Edit
- Glob
- Grep
- Bash
- AskUserQuestion
---
- # /as:project — Project Setup and Memory
-
- <!-- architecture-studio:harness-compatibility -->
- > Harness note: use `/as:<skill>` on Claude Code and `$<skill>` on Codex. Resolve `<skill-root>` as the directory containing this loaded `SKILL.md` and `<plugin-root>` as the plugin root that contains `skills/`, and use equivalent native tools when host tool names differ.
-
- `/as:project` is the only project-memory interface. It owns current facts in `PROJECT.md` and durable reasoning in `decisions/*.md` without combining those record types or duplicating a decision index.
-
- ## Commands
-
- ```text
- /as:project init
- /as:project status
- /as:project update
- /as:project remember <information>
- /as:project decisions
- /as:project record-decision <choice>
- /as:project supersede <number>
- /as:project migrate
- ```
-
- ## Hard boundaries
-
- 1. `PROJECT.md` contains sourced current facts. Decision identity, status, rationale, and history live only in `decisions/*.md`.
- 2. `PROJECT.md` links to `decisions/` but has no Decisions table and never copies decision metadata.
- 3. Never write `STUDIO.md`. `/as:studio` alone owns the manifest.
- 4. Never create a nested project beneath an existing `PROJECT.md`.
- 5. Every durable mutation is previewed and requires affirmative confirmation.
- 6. Preserve malformed records. A parse failure means unknown, not absent or approved.
- 7. Use project-relative links; never persist machine-specific absolute paths.
-
- ## Resolve the project root
-
- Run `<plugin-root>/skills/project/scripts/resolve-context.sh` from the current or explicitly supplied directory and follow `references/context-resolution.md`. `PROJECT.md` is the only implicit project boundary. A nearer project inside a monorepo wins over outer repository metadata; typed-record directories, task/time files, Claude instructions, git roots, and the current directory never establish a project. Stop on `invalid`; use the validated picker for `studio-picker`; and never write before one exact project is resolved.
-
- ## `/as:project init`
-
- 1. If the current path resolves an existing `PROJECT.md`, show status and do not create a nested project.
- 2. If a `STUDIO.md` is resolved, route creation to `/as:studio create-project`. Do not mutate the studio manifest and do not call back recursively after `/as:studio` has begun its confirmed orchestration.
- 3. Outside a studio, ask whether to initialize a studio or create a standalone project. Standalone creation requires explicit confirmation.
- 4. Gather the project name, optional ID, and exact target. Normalize the directory to lowercase kebab-case, prefixing a supplied ID. When no ID is supplied, use the folder slug as the stable local ID. Reject unsafe names, separators, dot segments, control characters, existing files, and non-empty directories. Never silently suffix a project identity.
- 5. Preview the exact path and full bundle. State that no git repository, ALPA account, or cloud service will be created.
- 6. After confirmation, run `<plugin-root>/skills/project/scripts/project-workspace.sh init <target> <name> <project-id> project` and verify every file and directory. Standalone projects always use a project-local task register; portfolio mode belongs to a studio.
- 7. Report the exact created path plus the `.agents/skills/` (Codex) and `.claude/skills/` (Claude Code) extension paths. Explain that the active harness should be restarted from the intended project directory if new project-only skills are not visible.
-
- ## `/as:project status`
-
- Read `PROJECT.md`, scan `decisions/*.md` directly, and summarize known facts, record counts, decision statuses, open tasks, and recent dated records. If an owning `STUDIO.md` declares portfolio task mode, read open tasks for this Project ID from the studio-root register; otherwise read the project register. Report duplicate decision numbers or malformed files. Do not consult or create a decision index.
-
- ## Facts: `update` and `remember`
-
- Every fact has a value, source, and date. Update an existing fact in place; append only genuinely new facts to the correct section. Git or the file-sharing system preserves history.
+ # /as:project
- For `/as:project remember` or a natural memory request:
+ Before acting, read the [host contract](../../docs/host-harness-contract.md), this component's [declaration](host-contract.json) (`skill:project`), and applicable [workspace semantics](../../docs/workspace-model.md). Load only the required modes from the [shared catalog](../../corpus/host-contracts.json).
- 1. Read the exact input and relevant project records.
- 2. Classify each item as fact-like, decision-like, or mixed:
- - fact-like states a current, sourceable project condition;
- - decision-like expresses a choice, selection, rejection, approval, or rationale;
- - mixed contains separable facts and choices.
- 3. Preview grouped destinations. Facts show the `PROJECT.md` section, value, source, and date. Decisions show the proposed decision record.
- 4. Ask which grouped changes to apply. Confirmation of a source record is not authorization to promote every candidate.
- 5. Write only selected items, then re-read and verify.
+ <!-- architecture-studio:harness-compatibility -->
+ Use the [host adapter](../../docs/host-adapters.md) for native invocation. Apply the [native workspace operations](../../docs/workspace-model.md#native-studio-and-project-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.
- When importing a selected item from minutes or a site report, require its exact project-relative path and stable item label. Read it and preserve its epistemic status. Reported, discussed, interpreted, proposed, or uncertain content cannot silently become a verified fact.
+ 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.
- ## Decisions
+ ## Before changing records
- ### `/as:project decisions`
+ Before persistent changes, follow the [native mutation sequence](../../docs/workspace-model.md#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.
- Discover `decisions/*.md` independently. Report number, title, status, and path for each parseable record, plus duplicate numbers, missing/unrecognized statuses, and malformed files. Filenames and files are canonical; no `PROJECT.md` table participates.
+ 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.
- ### `/as:project record-decision`
+ ## Fresh setup
- 1. Scan every decision filename. Allocate max parseable number + 1, zero-padded to four digits; never reuse a number because another record is malformed.
- 2. Capture one choice per record: context, at least two honestly stated options, status (`proposed` or `decided`), deciders, the call, consequences, and source links. Pull from conversation first and ask one grouped question only for missing pieces.
- 3. A proposed source item remains proposed unless the user affirmatively says the choice was made.
- 4. Preview the complete record and collision-free path. Wait for confirmation.
- 5. Write `decisions/NNNN-slug.md`, re-read it, and verify number, status, title, and backlinks. Do not update `PROJECT.md` with decision metadata.
+ 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.
- ### `/as:project supersede <number>`
+ The new shape is Format version 3, Document model 1. Preview the exact generated files; setup creates PROJECT.md, empty CSV registers, host instructions/skill roots and immutable folder identity, with no prose scaffold folders. It does not initialize Git, accounts or storage. No old-format converter exists. Existing live workspaces are not silently transformed. Inside a studio, studio orchestrates initialization and registration without recursive routing.
- 1. Resolve exactly one parseable decided record. Stop on missing, ambiguous, malformed, or already-superseded records.
- 2. Allocate a replacement normally. Preview the complete new record and the old record’s single status change together.
- 3. After confirmation, create and verify the replacement first; only then change the old status to `superseded by NNNN` and verify both cross-links.
- 4. On a later failure, preserve the verified replacement, report the exact partial state, and offer recovery against those records. Never allocate another replacement number for recovery.
+ `project.status` reports identity and document verification; statuses and project Kind are advisory, not permission gates. Follow the receive-owned native document verification specification for the document findings; a missing capability is reported separately from observed identity. Use `documents.query` for decisions and dated records, `tasks.list` for actions and `invoice.status` for ledger facts. Do not infer complete state from missing/unreadable evidence.
- ## `/as:project migrate`
+ ## Facts and decisions
- Migration removes the legacy Decisions table only when it is lossless:
+ For `project.facts` (`remember`/`update`), distinguish sourced facts, choices and unresolved information. Preview each destination and preserve provenance/date. Record only confirmed changes. Approval to save a source does not approve promoting all its statements.
- 1. Read `PROJECT.md` and discover all decision files.
- 2. Parse every legacy table row conservatively and match it to exactly one decision file by number plus compatible identity/status.
- 3. Missing files, duplicate numbers, malformed rows, or status disagreements block mutation. Report exact rows and paths.
- 4. If every row is accounted for, preview replacing the entire legacy section/table with the stable `decisions/` link while preserving all unrelated content byte-for-byte.
- 5. After confirmation, run the helper migration, re-read `PROJECT.md`, and verify the table is gone, the link exists, and all decision files are unchanged.
- 6. A project already using the link-only contract reports “already migrated” without mutation.
+ For `project.decision` (`record-decision`), capture one choice, context, actual options, deciders, proposed/decided status, rationale, consequences and exact sources. Allocate the next permanent decision number from registered decision records, without renumbering or reusing historical IDs. Prepare the authored Markdown with the bundled decision template; resolve its confirmed coordinates and register via `documents.register`, kind `decision`. Preserve unknowns and proposal status.
- ## Typed record handoffs
+ For supersession, receive a new decision document with `supersedes` referencing the original ID; preserve original bytes/history. Do not infer supersession from a later date alone. Query kind `decision` for listing; there is no separate path-based decision index.
- - Minutes and site reports may propose selected facts or decisions; `/as:project` re-reads and confirms them.
- - `/as:workplan` reads facts and decision files but writes only its plan.
- - `/as:tasklist` owns task rows in the canonical project or portfolio `TASKS.md`; `/as:studio` alone owns the studio task-mode setting; `/as:timetracker` owns `TIMELOG.md`.
- - Project registration state and archive belong to `/as:studio`, not `/as:project`.
+ ## Vocabularies
- ## Collaboration and harness boundary
+ `project.vocab` lists/adds/renames project phase, scope or originator values. Confirm unknown values; never invent them. A used value requires coordinated placement/link updates rather than an in-place manifest rename. Stage vocabulary belongs to studio (or the standalone manifest). An explicit request may create an empty phase folder; ordinary vocabulary edits do not precreate content directories.
- These are plain local files shared however the project already is. This local plugin creates no ALPA account or server. Cross-skill invocation and structured questions are enhancements; when unavailable, preserve completed work and print the exact follow-up command.
+ Tasks, time, invoices, minutes, site reports and plans retain their corresponding owners. Use stable registered document IDs plus item anchors for provenance. Every durable mutation is read back; raw conversation is not archived merely because a fact/decision is saved.