@mindfoldhq/trellis 0.5.0-beta.16 → 0.5.0-beta.17

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/overview.md

@@ -0,0 +1,55 @@
+# Local Customization Overview
+
+This directory is for local AI working in a user project where Trellis was installed through npm and `trellis init` has already been run. The AI should modify generated `.trellis/` and platform directories inside the project, not Trellis CLI upstream source code.
+
+## First Determine What The User Actually Wants To Change
+
+| User wording | Read first |
+| --- | --- |
+| "Change the Trellis flow / phases / next prompt" | `change-workflow.md` |
+| "Change task creation, status, archive, or hooks" | `change-task-lifecycle.md` |
+| "AI did not read context / change injected content" | `change-context-loading.md` |
+| "A platform hook is not behaving as expected" | `change-hooks.md` |
+| "Change implement/check/research agent behavior" | `change-agents.md` |
+| "Add a skill/command/workflow/prompt" | `change-skills-or-commands.md` |
+| "Adjust the project spec structure" | `change-spec-structure.md` |
+| "Add team conventions and local notes" | `add-project-local-conventions.md` |
+
+## General Operation Order
+
+1. **Confirm platform and directories**: inspect which directories exist, such as `.claude/`, `.codex/`, `.cursor/`.
+2. **Confirm the current active task**: run `python3 ./.trellis/scripts/task.py current --source`.
+3. **Read the local source of truth**: prefer `.trellis/workflow.md`, `.trellis/config.yaml`, and relevant platform files.
+4. **Modify narrowly**: edit only files related to the user's request.
+5. **Synchronize semantics**: if a shared flow changes, check whether platform entry points also need changes; if a platform entry changes, check whether `.trellis/workflow.md` still agrees.
+
+## Local File Priority
+
+| Layer | Files |
+| --- | --- |
+| Workflow | `.trellis/workflow.md` |
+| Project configuration | `.trellis/config.yaml` |
+| Task material | `.trellis/tasks/<task>/` |
+| Project specs | `.trellis/spec/` |
+| Runtime scripts | `.trellis/scripts/` |
+| Platform integration | `.claude/`, `.codex/`, `.cursor/`, `.opencode/`, and similar directories |
+| Shared skill | `.agents/skills/` |
+
+## Things Not To Do By Default
+
+- Do not edit the global npm install directory.
+- Do not edit `node_modules/@mindfoldhq/trellis`.
+- Do not assume the user has the Trellis GitHub repository.
+- Do not overwrite local files already modified by the user with default templates.
+- Do not put team project rules into public `trellis-meta`; project rules belong in `.trellis/spec/` or a local skill.
+
+## When To Inspect Upstream Source
+
+Switch to an upstream source-code perspective only when the user explicitly expresses one of these goals:
+
+- "I want to open a PR to Trellis"
+- "I want to change npm package publish contents"
+- "I want to fork Trellis"
+- "I want to modify the generation logic for `trellis init/update`"
+
+Otherwise, default to modifying local Trellis files inside the user project.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/context-injection.md

@@ -0,0 +1,68 @@
+# Local Context Injection System
+
+Trellis context injection aims to make AI read the right files at the right time instead of relying on model memory. In a user project, injection is implemented by `.trellis/` scripts together with platform hooks, agents, and skills.
+
+## Injected Context Types
+
+| Type | Source | Purpose |
+| --- | --- | --- |
+| session context | `.trellis/scripts/get_context.py` | Current developer, git status, active task, active tasks, journal, packages. |
+| workflow context | `.trellis/workflow.md` | Current Trellis flow and next action. |
+| spec context | `.trellis/spec/` + task JSONL | Specs that must be followed during implementation/checking. |
+| task context | `.trellis/tasks/<task>/prd.md`, `info.md`, `research/` | Current task requirements, design, and research. |
+| platform context | Platform hooks/settings/agents | Lets different AI tools read the files above through their own mechanisms. |
+
+## session-start
+
+Platforms with session-start support inject a Trellis overview when a session starts, clears, compacts, or receives a similar event. Injected content usually includes:
+
+- workflow summary.
+- current task status.
+- active tasks.
+- spec index paths.
+- developer identity and git status.
+
+If the user feels the AI does not know the current task in a new session, first check whether the platform's session-start hook or equivalent mechanism is installed and running.
+
+## workflow-state
+
+workflow-state is a lightweight hint injected around each user turn. Based on current task status, it selects a block from `.trellis/workflow.md`, such as `no_task`, `planning`, `in_progress`, or `completed`.
+
+If the user wants to change "what the AI should do next in a given state," edit the corresponding state block in `.trellis/workflow.md` first.
+
+## sub-agent context
+
+Implement and check agents need task context. Trellis has two loading modes:
+
+1. **hook push**: a platform hook injects `prd.md` and the files referenced by `implement.jsonl` / `check.jsonl` before the agent starts.
+2. **agent pull**: the agent definition instructs the agent to read the active task, PRD, and JSONL context after startup.
+
+In both modes, JSONL files in the task directory are the key interface.
+
+## JSONL Reading Rules
+
+`implement.jsonl` and `check.jsonl` contain one JSON object per line:
+
+```jsonl
+{"file": ".trellis/spec/backend/index.md", "reason": "Backend rules"}
+```
+
+Readers should skip seed rows without a `file` field. When configuring JSONL, the AI should include only spec/research files, not pre-register code files that will be modified.
+
+## Active Task And Context Key
+
+Active task state lives in `.trellis/.runtime/sessions/` and is isolated per session. Hooks try to resolve the context key from platform events, environment variables, transcript paths, or `TRELLIS_CONTEXT_ID`.
+
+If shell commands cannot see the same context key, `task.py current --source` may report no active task. In that case, check whether the platform passes session identity into the shell instead of hand-writing a global current-task file.
+
+## Local Customization Points
+
+| Need | Edit location |
+| --- | --- |
+| Change session-start injected content | The platform's `session-start` hook or plugin file. |
+| Change per-turn workflow-state rules | State blocks in `.trellis/workflow.md` and the platform workflow-state hook. |
+| Change how sub-agents read context | Platform agent definitions, the `inject-subagent-context` hook, or agent preludes. |
+| Change JSONL validation/display | `.trellis/scripts/common/task_context.py`. |
+| Change active task resolution | `.trellis/scripts/common/active_task.py`. |
+
+When modifying context injection, verify two things: new sessions can see the correct task, and sub-agents can see the correct PRD/spec/research.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/generated-files.md

@@ -0,0 +1,80 @@
+# Local Files Generated After Init
+
+`trellis init` writes the Trellis runtime into the user project. Later, `trellis update` tries to update Trellis-managed template files, but it uses `.trellis/.template-hashes.json` to determine which files have already been modified by the user.
+
+This page only describes files that are visible and editable inside the user project.
+
+## `.trellis/`
+
+```text
+.trellis/
+├── workflow.md
+├── config.yaml
+├── .developer
+├── .version
+├── .template-hashes.json
+├── .runtime/
+├── scripts/
+├── spec/
+├── tasks/
+└── workspace/
+```
+
+| Path | Usually editable? | Notes |
+| --- | --- | --- |
+| `.trellis/workflow.md` | Yes | Local workflow documentation and AI routing rules. |
+| `.trellis/config.yaml` | Yes | Project configuration, hooks, packages, journal line limits, and related settings. |
+| `.trellis/spec/` | Yes | Project specs, intended to be updated regularly by users and AI. |
+| `.trellis/tasks/` | Yes | Task material and research artifacts, maintained by the task workflow. |
+| `.trellis/workspace/` | Yes | Session records, usually written by `add_session.py`. |
+| `.trellis/scripts/` | Carefully | Local runtime. It can be customized, but only after understanding the call chain. |
+| `.trellis/.runtime/` | No | Runtime state, usually written automatically by hooks/scripts. |
+| `.trellis/.developer` | Carefully | Current developer identity. |
+| `.trellis/.version` | No | Trellis version record used by update/migration logic. |
+| `.trellis/.template-hashes.json` | No | Template hash record. Do not hand-write business rules here. |
+
+## Platform Directories
+
+Different platforms generate different directories. Common categories:
+
+| Category | Example paths | Purpose |
+| --- | --- | --- |
+| hooks | `.claude/hooks/`, `.codex/hooks/`, `.cursor/hooks/` | Inject session context, workflow-state, and sub-agent context. |
+| settings | `.claude/settings.json`, `.codex/hooks.json`, `.qoder/settings.json` | Tell the platform when to run hooks or plugins. |
+| agents | `.claude/agents/`, `.codex/agents/`, `.kiro/agents/` | Define agents such as `trellis-research`, `trellis-implement`, and `trellis-check`. |
+| skills | `.claude/skills/`, `.agents/skills/`, `.qoder/skills/` | Skills that auto-trigger or can be read by AI. |
+| commands/prompts/workflows | `.cursor/commands/`, `.github/prompts/`, `.windsurf/workflows/` | Explicit user-invoked command or workflow entry points. |
+
+When modifying a platform directory, also confirm whether `.trellis/workflow.md` still describes the same flow.
+
+## Meaning Of Template Hashes
+
+`.trellis/.template-hashes.json` records the content hash from the last time Trellis wrote a template file. `trellis update` uses it to distinguish three cases:
+
+| Case | Update behavior |
+| --- | --- |
+| File was not modified by the user | It can be updated automatically. |
+| File was modified by the user | Prompt the user to overwrite, keep, or generate `.new`. |
+| File is no longer a current template | It may be deleted, renamed, or preserved according to migration rules. |
+
+When an AI customizes local Trellis files, it does not need to maintain hashes manually. It is normal for Trellis update to recognize the result as "modified by the user."
+
+## Local Customization Boundaries
+
+Editable by default:
+
+- `.trellis/workflow.md`
+- `.trellis/config.yaml`
+- `.trellis/spec/**`
+- `.trellis/scripts/**`
+- Platform hooks, settings, agents, skills, commands, prompts, and workflows
+
+Do not edit by default:
+
+- Global npm install directory
+- `node_modules/@mindfoldhq/trellis`
+- Trellis GitHub repository source code
+- Concrete state files under `.trellis/.runtime/**`
+- Hash contents inside `.trellis/.template-hashes.json`
+
+Switch to the Trellis CLI source-code perspective only when the user explicitly wants to contribute upstream.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/overview.md

@@ -0,0 +1,51 @@
+# Local Trellis Architecture Overview
+
+`trellis-meta` is for user projects that have already run `trellis init`. The user's machine usually has only the npm-installed `trellis` command plus the Trellis files generated inside the project; it may not have the Trellis CLI source code.
+
+Therefore, when an AI uses this skill, the default customization target is local files inside the user project:
+
+- `.trellis/`: workflow, tasks, specs, memory, scripts, and runtime state.
+- Platform directories: `.claude/`, `.codex/`, `.cursor/`, `.opencode/`, `.kiro/`, `.gemini/`, `.qoder/`, `.codebuddy/`, `.github/`, `.factory/`, `.pi/`, `.kilocode/`, `.agent/`, `.windsurf/`, and similar directories.
+- Shared skill layer: `.agents/skills/`.
+
+Do not default to guiding the user to fork the Trellis CLI repository. Treat upstream source code as the operating target only when the user explicitly says they want to change Trellis upstream source, publish an npm package, or contribute a PR.
+
+## Local System Model
+
+Trellis provides three layers inside a user project:
+
+1. **Workflow layer**: `.trellis/workflow.md` defines phases, routing, next actions, and prompt blocks.
+2. **Persistence layer**: `.trellis/tasks/`, `.trellis/spec/`, and `.trellis/workspace/` store tasks, specs, and session memory.
+3. **Platform integration layer**: hooks, settings, agents, skills, commands, prompts, and workflows in platform directories connect the Trellis workflow to different AI tools.
+
+All three layers live inside the user project, so an AI can read and modify them directly.
+
+## Core Paths
+
+| Path | Purpose |
+| --- | --- |
+| `.trellis/workflow.md` | Workflow phases, skill routing, and workflow-state prompt blocks. |
+| `.trellis/config.yaml` | Project configuration, task lifecycle hooks, monorepo package configuration, and journal configuration. |
+| `.trellis/spec/` | The user's project-specific coding conventions and thinking guides. |
+| `.trellis/tasks/` | Each task's PRD, technical notes, research files, and JSONL context. |
+| `.trellis/workspace/` | Per-developer journals and cross-session memory. |
+| `.trellis/scripts/` | Local Python runtime used by commands, hooks, and context injection. |
+| `.trellis/.runtime/` | Session-level runtime state, such as the current task pointer. |
+| `.trellis/.template-hashes.json` | Template hashes for Trellis-managed files, used by update to determine whether local files were modified by the user. |
+
+## AI Customization Principles
+
+1. **Find the local source of truth first**: Do not edit from memory. Read `.trellis/workflow.md`, `.trellis/config.yaml`, the relevant platform directory, and related task files first.
+2. **Edit the user project, not the npm package cache**: Modify generated files inside the project, not `node_modules` or the global npm install directory.
+3. **Keep platform files aligned with `.trellis/`**: If workflow routing changes, also check whether platform skills or commands still describe the same flow.
+4. **Put project-specific rules in `.trellis/spec/` or a local skill**: Do not put team conventions into `trellis-meta`.
+5. **Preserve user changes**: If a file was already modified locally, work from the current content instead of overwriting it with a default template.
+
+## How To Use This Directory
+
+- To understand which files exist after init, read `generated-files.md`.
+- To change phases, routing, or next actions, read `workflow.md`.
+- To change the task model, JSONL context, or active task behavior, read `task-system.md`.
+- To change coding convention injection, read `spec-system.md`.
+- To understand journals and cross-session memory, read `workspace-memory.md`.
+- To change hooks or sub-agent context loading, read `context-injection.md`.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/spec-system.md

@@ -0,0 +1,102 @@
+# Local Spec System
+
+`.trellis/spec/` is the user's project-specific engineering spec library. Trellis is not about making AI memorize conventions; it injects relevant specs or requires the AI to read them at the right time.
+
+## Directory Model
+
+A common single-repository structure:
+
+```text
+.trellis/spec/
+├── backend/
+│   ├── index.md
+│   └── ...
+├── frontend/
+│   ├── index.md
+│   └── ...
+└── guides/
+    ├── index.md
+    └── ...
+```
+
+A common monorepo structure:
+
+```text
+.trellis/spec/
+├── cli/
+│   ├── backend/
+│   │   ├── index.md
+│   │   └── ...
+│   └── unit-test/
+│       ├── index.md
+│       └── ...
+├── docs-site/
+│   └── docs/
+│       ├── index.md
+│       └── ...
+└── guides/
+    ├── index.md
+    └── ...
+```
+
+`index.md` is the entry point for each layer. It should list the Pre-Development Checklist and Quality Check. Specific guidelines live in other Markdown files in the same directory.
+
+## Package Configuration
+
+`.trellis/config.yaml` can declare packages:
+
+```yaml
+packages:
+  cli:
+    path: packages/cli
+  docs-site:
+    path: docs-site
+    type: submodule
+default_package: cli
+```
+
+The AI can run:
+
+```bash
+python3 ./.trellis/scripts/get_context.py --mode packages
+```
+
+This command lists packages and spec layers for the current project. Use this output as the reference when configuring context JSONL.
+
+## How Specs Enter Tasks
+
+Before a task enters implementation, Phase 1.3 should write relevant specs into `implement.jsonl` / `check.jsonl`:
+
+```jsonl
+{"file": ".trellis/spec/cli/backend/index.md", "reason": "CLI backend conventions"}
+{"file": ".trellis/spec/cli/unit-test/conventions.md", "reason": "Test expectations"}
+```
+
+Sub-agents or platform preludes read these JSONL files and load the referenced specs. On platforms without sub-agent support, the AI should read the relevant specs directly according to the workflow.
+
+## What Specs Should Contain
+
+Specs should contain executable engineering conventions for the project, not generic best practices:
+
+- Where files should live.
+- How error handling should be expressed.
+- Input/output contracts for APIs, hooks, and commands.
+- Patterns that are forbidden.
+- Cases that require tests.
+- Project-specific pitfalls and how to avoid them.
+
+When the AI learns a new rule during implementation or debugging, it should update `.trellis/spec/` rather than only summarizing it in chat.
+
+## Local Customization Points
+
+| Need | Edit location |
+| --- | --- |
+| Add a new spec layer | `.trellis/spec/<package>/<layer>/index.md` and corresponding guideline files. |
+| Change monorepo spec mapping | `packages` / `default_package` / `spec_scope` in `.trellis/config.yaml`. |
+| Change which specs AI reads before implementation | The task's `implement.jsonl`. |
+| Change which specs AI reads during checking | The task's `check.jsonl`. |
+| Change when specs should be updated | Phase 3.3 in `.trellis/workflow.md` and the `trellis-update-spec` skill. |
+
+## Boundaries
+
+`.trellis/spec/` is the user's project specification, not a permanent copy of Trellis built-in templates. The AI should encourage the user to update it according to the actual project code instead of treating Trellis default templates as immutable documents.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/task-system.md

@@ -0,0 +1,101 @@
+# Local Task System
+
+The Trellis task system is stored entirely under `.trellis/tasks/` in the user project. Each task is a directory containing requirements, context, research, state, and relationship information.
+
+## Task Directory Structure
+
+```text
+.trellis/tasks/
+├── 04-28-example-task/
+│   ├── task.json
+│   ├── prd.md
+│   ├── info.md
+│   ├── implement.jsonl
+│   ├── check.jsonl
+│   └── research/
+└── archive/
+    └── 2026-04/
+```
+
+| File | Purpose |
+| --- | --- |
+| `task.json` | Task metadata: status, assignee, priority, branch, parent/child tasks, and similar fields. |
+| `prd.md` | Requirements document; the most important business context during implementation. |
+| `info.md` | Optional technical design. |
+| `implement.jsonl` | List of spec/research files the implement agent must read first. |
+| `check.jsonl` | List of spec/research files the check agent must read first. |
+| `research/` | Research artifacts. Complex findings should not live only in chat. |
+
+## `task.json`
+
+`task.json` records task status and metadata. Common fields:
+
+| Field | Meaning |
+| --- | --- |
+| `id` / `name` / `title` | Task identity and title. |
+| `status` | Status such as `planning`, `in_progress`, `review`, or `completed`. |
+| `priority` | `P0`, `P1`, `P2`, `P3`. |
+| `creator` / `assignee` | Creator and assignee. |
+| `package` | Target package in a monorepo; may be empty. |
+| `branch` / `base_branch` | Working branch and PR target branch. |
+| `children` / `parent` | Parent/child task relationships. |
+| `commit` / `pr_url` | Commit and PR information after completion. |
+| `meta` | Extension fields. |
+
+The AI should not treat phase numbers as task status. Task progress is mainly determined by `status`, `prd.md`, whether JSONL context is configured, and the phase descriptions in `workflow.md`.
+
+## Active Task
+
+The user sees a "current task," but Trellis stores active task state per session.
+
+```text
+.trellis/.runtime/sessions/<context-key>.json
+```
+
+`task.py start` writes the task path into the runtime session file for the current session. `task.py current --source` shows the current task and where it came from. Different AI windows can point to different tasks without overwriting each other.
+
+If the platform or shell environment has no stable session identity, `task.py start` may be unable to set the active task. The AI should read the error, inspect the platform hook/session environment, and not fall back to a shared global pointer.
+
+## JSONL Context
+
+`implement.jsonl` and `check.jsonl` are context manifests for sub-agents to read first.
+
+Format:
+
+```jsonl
+{"file": ".trellis/spec/cli/backend/index.md", "reason": "Backend conventions"}
+{"file": ".trellis/tasks/04-28-example/research/api.md", "reason": "API research"}
+```
+
+Rules:
+
+- Include spec and research files.
+- Do not include code files that are about to be modified.
+- Do not treat temporary conclusions in chat as the only context.
+- Seed rows have no `file` field; they only prompt the AI to fill in real entries.
+
+## Common Commands
+
+```bash
+python3 ./.trellis/scripts/task.py create "<title>" --slug <slug>
+python3 ./.trellis/scripts/task.py start <task>
+python3 ./.trellis/scripts/task.py current --source
+python3 ./.trellis/scripts/task.py add-context <task> implement <file> <reason>
+python3 ./.trellis/scripts/task.py validate <task>
+python3 ./.trellis/scripts/task.py finish
+python3 ./.trellis/scripts/task.py archive <task>
+```
+
+When modifying the task system, the AI should prefer script commands to maintain structure. Edit JSON/Markdown directly only when scripts do not cover the need.
+
+## Local Customization Points
+
+| Need | Edit location |
+| --- | --- |
+| Change the default task template | `.trellis/scripts/common/task_store.py` and task creation instructions. |
+| Change status semantics | `.trellis/workflow.md`, workflow-state hook logic, and task usage conventions. |
+| Add task lifecycle actions | `hooks.after_*` in `.trellis/config.yaml`. |
+| Change context rules | Phase 1.3 in `.trellis/workflow.md` and related platform agent/hook instructions. |
+| Change archive policy | `.trellis/scripts/common/task_store.py` / `task_utils.py`. |
+
+These are local files in the user project. Do not default to editing Trellis CLI source code unless the user wants to contribute upstream.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/workflow.md

@@ -0,0 +1,75 @@
+# Local Workflow System
+
+`.trellis/workflow.md` is the Trellis workflow source of truth inside the user project. An AI does not need Trellis source code to understand how the current project should move tasks forward; this file is enough.
+
+## File Responsibilities
+
+`.trellis/workflow.md` has three responsibilities:
+
+1. **Explain workflow phases**: Plan, Execute, Finish.
+2. **Define skill routing**: which skill or agent the AI should use when the user expresses a certain intent.
+3. **Provide workflow-state prompt blocks**: hooks can inject the prompt block for the current state into the conversation.
+
+## Current Phase Model
+
+```text
+Phase 1: Plan    -> clarify what to build, produce prd.md and required research
+Phase 2: Execute -> implement against the PRD and specs, then check
+Phase 3: Finish  -> final verification, preserve lessons, and wrap up
+```
+
+Each phase contains numbered steps, such as `1.3 Configure context`. These numbers are not runtime fields in `task.json`; they are workflow structure for AI and humans to read.
+
+## Skill Routing
+
+`workflow.md` separates routing by platform capability:
+
+- Platforms with sub-agent support: dispatch `trellis-implement` by default for implementation and `trellis-check` for checking.
+- Platforms without sub-agent support: the main session reads skills such as `trellis-before-dev`, then executes directly.
+
+When changing local AI behavior, update the routing descriptions in `workflow.md` first, then check whether the corresponding platform skill, command, or agent files need to stay in sync.
+
+## Workflow-State Prompt Blocks
+
+The bottom of `workflow.md` can contain state blocks like this:
+
+```text
+[workflow-state:no_task]
+...
+[/workflow-state:no_task]
+```
+
+Hooks choose the right block based on current task status and inject it into the conversation. Common states include:
+
+| State | Meaning |
+| --- | --- |
+| `no_task` | The current session has no active task. |
+| `planning` | The task is still in requirements, research, or context configuration. |
+| `in_progress` | The task has entered implementation and checking. |
+| `completed` | The task is complete and waiting for wrap-up or archive. |
+
+If the user wants to change policies such as "whether to create a task when there is no task," "when task creation may be skipped," or "whether sub-agents are required," edit these state blocks and the routing table above them.
+
+## Local Modification Patterns
+
+Common changes:
+
+| Goal | Edit point |
+| --- | --- |
+| Add a phase | Update the Phase Index, phase body, routing, and state blocks. |
+| Change task creation policy | Update the `no_task` state block and Phase 1 description. |
+| Change the default implementation/check path | Update Phase 2 and skill routing. |
+| Change the wrap-up flow | Update Phase 3 and `finish-work` related descriptions. |
+| Change platform differences | Update routing descriptions grouped by platform. |
+
+After editing, make the AI reread `.trellis/workflow.md`; do not assume the flow from the old conversation is still valid.
+
+## Relationship To Platform Files
+
+`workflow.md` is the semantic center of the local workflow, but each platform can also have its own entry files:
+
+- skills, such as `trellis-brainstorm` and `trellis-check`.
+- commands/prompts/workflows, such as continue and finish-work.
+- hooks, such as session-start or workflow-state injection.
+
+If only `workflow.md` changes, platform entry files may still contain old language. When the user wants to change "what the AI actually does," also inspect the relevant platform directory.

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/workspace-memory.md

@@ -0,0 +1,71 @@
+# Local Workspace Memory System
+
+`.trellis/workspace/` stores cross-session memory. Its purpose is to let AI and humans understand what happened before across different windows and different days.
+
+## Directory Structure
+
+```text
+.trellis/workspace/
+├── index.md
+└── <developer>/
+    ├── index.md
+    ├── journal-1.md
+    └── journal-2.md
+```
+
+| File | Purpose |
+| --- | --- |
+| `.trellis/.developer` | Current developer identity. |
+| `.trellis/workspace/index.md` | Global workspace overview. |
+| `.trellis/workspace/<developer>/index.md` | Session index for a developer. |
+| `.trellis/workspace/<developer>/journal-N.md` | Session journal. |
+
+## Developer Identity
+
+Run this the first time:
+
+```bash
+python3 ./.trellis/scripts/init_developer.py <name>
+```
+
+This creates `.trellis/.developer` and the corresponding workspace directory. The AI should not change developer identity casually; if the identity is wrong, first confirm who is using the current project.
+
+## Journal
+
+`journal-N.md` records completed or partially completed work from each session. By default, each journal holds about 2000 lines; after that it rotates to the next file.
+
+Common command for recording a session:
+
+```bash
+python3 ./.trellis/scripts/add_session.py \
+  --title "Session title" \
+  --summary "What changed" \
+  --commit "abc1234"
+```
+
+Planning or review work without a commit can also be recorded by using `--no-commit` or an empty commit value.
+
+## Relationship Between Workspace Memory And Tasks
+
+| System | What it stores |
+| --- | --- |
+| `.trellis/tasks/` | Requirements, design, research, and state for a specific task. |
+| `.trellis/workspace/` | Work records across tasks and sessions. |
+| `.trellis/spec/` | Engineering knowledge preserved as long-term conventions. |
+
+If information is only useful for the current task, put it in the task directory.  
+If information describes what happened in the current session, put it in the workspace journal.  
+If information should be followed every time code is written in the future, put it in spec.
+
+## Local Customization Points
+
+| Need | Edit location |
+| --- | --- |
+| Change maximum journal lines | `max_journal_lines` in `.trellis/config.yaml`. |
+| Change session auto-commit message | `session_commit_message` in `.trellis/config.yaml`. |
+| Change session content format | `.trellis/scripts/add_session.py`. |
+| Change how workspace is displayed in context | `.trellis/scripts/common/session_context.py`. |
+
+## AI Usage Rules
+
+The AI should not treat workspace as the only source of truth. When resuming a task, read the current task first, then use workspace for background. After a task is complete, record important process notes in workspace; if long-term rules emerged, update spec.