aligndev 0.18.0 → 0.20.0

package/templates/guide/playbook/working-session.md

@@ -169,10 +169,10 @@ For new single-project work where the user explicitly says there is no ticket or
 5. Run `{{ALIGNFIRST}} sync`.
 
 {{#openclaw}}
-The bot owns this reservation and the request capture; the coder receives TICKET_ID. Do not use `{{ALIGNDEV}} code new --no-ticket`: TICKET_ID must exist before delegation, for the request file and the workspace. Continue to workspace setup with the side ticket as TICKET_ID, then run the coding protocol from the returned linked worktree.
+The bot owns this reservation and the request capture; the agent receives TICKET_ID. Do not use `{{ALIGNDEV}} code new --no-ticket`: TICKET_ID must exist before delegation, for the request file and the workspace. Continue to workspace setup with the side ticket as TICKET_ID, then run the coding protocol from the returned linked worktree.
 {{/openclaw}}
 {{#codingAgent}}
-You own this reservation and the request capture; the coder receives TICKET_ID. Do not use `{{ALIGNDEV}} code new --no-ticket`: TICKET_ID must exist before delegation, for the request file and the workspace. Continue to workspace setup with the side ticket as TICKET_ID, then run the coding protocol from the returned linked worktree.
+You own this reservation and the request capture; the agent receives TICKET_ID. Do not use `{{ALIGNDEV}} code new --no-ticket`: TICKET_ID must exist before delegation, for the request file and the workspace. Continue to workspace setup with the side ticket as TICKET_ID, then run the coding protocol from the returned linked worktree.
 {{/codingAgent}}
 
 {{#openclaw}}
@@ -230,11 +230,11 @@ Only when the message is unambiguously about chat content ("summarize this threa
 Only when the message is unambiguously about chat content ("summarize this conversation", "what does this mean") should you treat it as a regular conversation.
 {{/codingAgent}}
 
-**Question, advice, or a design opinion.** The substance comes from the coder, which reads the repository. Follow `{{ALIGNDEV}} guide consultation`. No code change unless asked.
+**Question, advice, or a design opinion.** The substance comes from the agent, which reads the repository. Follow `{{ALIGNDEV}} guide consultation`. No code change unless asked.
 
 ### Read-only questions
 
-A codebase question, advice, or a brainstorming follows `{{ALIGNDEV}} guide consultation`. Read it fully. It resolves the project, delegates the complete question to the coder, and records the discussion when one is worth keeping.
+A codebase question, advice, or a brainstorming follows `{{ALIGNDEV}} guide consultation`. Read it fully. It resolves the project, delegates the complete question to the agent, and records the discussion when one is worth keeping.
 
 A request for a ticket's progress follows "Status update" instead; it needs that ticket's history and workspace state.
 
@@ -257,32 +257,32 @@ When one project owns a detailed change request, preserve it before delegation:
 When Step 5 reserved a side ticket `side-N`, the request is already captured. Continue through project workspace setup and delegate from the linked worktree.
 
 {{#openclaw}}
-Skip this capture workflow for a multi-project request with no main project and for operational work such as workspace cleanup or base-branch refresh. Delegate those requests to the coder without an AlignFirst protocol.
+Skip this capture workflow for a multi-project request with no main project and for operational work such as workspace cleanup or base-branch refresh. Delegate those requests to the agent without an AlignFirst protocol.
 {{/openclaw}}
 {{#codingAgent}}
-Skip this capture workflow for operational work such as workspace cleanup or base-branch refresh. Delegate those requests to the coder without an AlignFirst protocol.
+Skip this capture workflow for operational work such as workspace cleanup or base-branch refresh. Delegate those requests to the agent without an AlignFirst protocol.
 {{/codingAgent}}
 
 {{#openclaw}}
 ### Multi-project and operational work
 
-Delegate a multi-project request with no main project, workspace cleanup, base-branch refresh, and similar operational work to the coder without an AlignFirst protocol. Refresh `{{ALIGNDEV}} project list --json` when the affected project set is not already recorded. Run one project-bound coder session from each affected PROJECT_PATH and coordinate their results in the thread. For a base-branch refresh, the coder owns the initial fetch, the fast-forward, and any dependency, build, or migration refresh; an already-current branch is one possible result of that delegation. Supply the ticket ID when one identifies the workspaces and name every configured global tool the run can use. Set up project workspaces only when the operation needs them.
+Delegate a multi-project request with no main project, workspace cleanup, base-branch refresh, and similar operational work to the agent without an AlignFirst protocol. Refresh `{{ALIGNDEV}} project list --json` when the affected project set is not already recorded. Run one project-bound agent session from each affected PROJECT_PATH and coordinate their results in the thread. For a base-branch refresh, the agent owns the initial fetch, the fast-forward, and any dependency, build, or migration refresh; an already-current branch is one possible result of that delegation. Supply the ticket ID when one identifies the workspaces and name every configured global tool the run can use. Set up project workspaces only when the operation needs them.
 {{/openclaw}}
 {{#codingAgent}}
 ### Operational work
 
-Delegate workspace cleanup, base-branch refresh, and similar operational work to the coder without an AlignFirst protocol, from PROJECT_PATH. For a base-branch refresh, the coder owns the initial fetch, the fast-forward, and any dependency, build, or migration refresh; an already-current branch is one possible result of that delegation. Supply the ticket ID when one identifies the workspaces and name every configured global tool the run can use. Set up project workspaces only when the operation needs them.
+Delegate workspace cleanup, base-branch refresh, and similar operational work to the agent without an AlignFirst protocol, from PROJECT_PATH. For a base-branch refresh, the agent owns the initial fetch, the fast-forward, and any dependency, build, or migration refresh; an already-current branch is one possible result of that delegation. Supply the ticket ID when one identifies the workspaces and name every configured global tool the run can use. Set up project workspaces only when the operation needs them.
 {{/codingAgent}}
 
 ### What you delegate vs do
 
 Lean toward delegating; the less you touch the project directly, the better.
 
-Delegate to the coder: workspace/branch/worktree creation, writing code (`alignfirst` protocols), commits, pushes, opening MR/PRs.
+Delegate to the agent: workspace/branch/worktree creation, writing code (`alignfirst` protocols), commits, pushes, opening MR/PRs.
 
-Thinking is delegated too. When you need *ideas*, a *design* direction, an *opinion*, or an approach — for the user or for your own next step — put the question to the coder and build on its answer. Never brainstorm alone: the coder grounds its ideas in the codebase; yours would come from memory. `{{ALIGNDEV}} guide consultation` is the procedure.
+Thinking is delegated too. When you need *ideas*, a *design* direction, an *opinion*, or an approach — for the user or for your own next step — put the question to the agent and build on its answer. Never brainstorm alone: the agent grounds its ideas in the codebase; yours would come from memory. `{{ALIGNDEV}} guide consultation` is the procedure.
 
-Global tools go in the prompt. Run `{{ALIGNDEV}} code` from the linked workspace for changes and from PROJECT_PATH only when the procedure explicitly works in the main worktree. The coder knows only that directory's project context: it can run the globally installed tools your own context lists, but it doesn't know they exist. When a delegated task can use one, name it in the prompt as **globally installed**. A task you would have kept because it needs such a tool is one more thing to delegate.
+Global tools go in the prompt. Run `{{ALIGNDEV}} code` from the linked workspace for changes and from PROJECT_PATH only when the procedure explicitly works in the main worktree. The agent knows only that directory's project context: it can run the globally installed tools your own context lists, but it doesn't know they exist. When a delegated task can use one, name it in the prompt as **globally installed**. A task you would have kept because it needs such a tool is one more thing to delegate.
 
 Every single-project change delegation carries TICKET_ID in the `{{ALIGNDEV}} code` invocation or message as the delegation guide allows. Read-only questions omit the ticket option; a ticket mentioned by the user stays in the question's context. Operational maintenance may instead identify its existing branches and workspaces directly.
 
@@ -294,33 +294,33 @@ Launching a background run ends the turn: the closing message is the launch ackn
 
 ### The plan is not a gate
 
-Coding work follows spec → plan → implementation, as the delegation guide describes. That chain is how the coder works, not a series of checkpoints for the user: run it end to end. When the plan lands, launch the implementation in a new session right away and tell the user in one line that it started.
+Coding work follows spec → plan → implementation, as the delegation guide describes. That chain is how the agent works, not a series of checkpoints for the user: run it end to end. When the plan lands, launch the implementation in a new session right away and tell the user in one line that it started.
 
-The coder usually has no question. When it does, answer it: a technical question — architecture, existing behavior, anything the codebase answers — you settle yourself, pushing the coder to investigate. A functional or product question goes to the user, and you relay their answer back.
+The agent usually has no question. When it does, answer it: a technical question — architecture, existing behavior, anything the codebase answers — you settle yourself, pushing the agent to investigate. A functional or product question goes to the user, and you relay their answer back.
 
-### Plan files are the coder's material
+### Plan files are the agent's material
 
-Before acting on any file the user names under `.plans/`, run `{{ALIGNFIRST}} sync`. Then never read a plan file, main plans included. A request to execute a plan means: read the spec next to it when one exists — same directory, same leading letter (`A1-spec.md` for `A2-plan.md`) — then hand the plan's path to the coder, as the delegation guide describes.
+Before acting on any file the user names under `.plans/`, run `{{ALIGNFIRST}} sync`. Then never read a plan file, main plans included. A request to execute a plan means: read the spec next to it when one exists — same directory, same leading letter (`A1-spec.md` for `A2-plan.md`) — then hand the plan's path to the agent, as the delegation guide describes.
 
 For the `.plans/` directory's task directories, cycles, filenames, and artifact conventions, run `{{ALIGNFIRST}} guide` from PROJECT_PATH; its output ends with the ticket directory and work file rules. Project instructions only define whether and how the directory is shared.
 
 ### Hand-written changes in `.plans/`
 
-After writing or editing any file under `.plans/` yourself, run `{{ALIGNFIRST}} sync`. A change written by the coder needs nothing — the coder syncs its own.
+After writing or editing any file under `.plans/` yourself, run `{{ALIGNFIRST}} sync`. A change written by the agent needs nothing — the agent syncs its own.
 
 ### The project's entry points
 
 A project has up to three entry points:
 
 - `README.md` — presentation, getting-started procedure…
-- `DEVELOPERS.md` — the coder's user, human or AI: you. Read it at DEVELOPERS_PATH.
-- `AGENTS.md` — the coder. When the project's instructions come from its companion, the companion's `.alignfirst.md` replaces it for the coder, and `{{ALIGNFIRST}} context` prints it.
+- `DEVELOPERS.md` — the agent's user, human or AI: you. Read it at DEVELOPERS_PATH.
+- `AGENTS.md` — the agent. When the project's instructions come from its companion, the companion's `.alignfirst.md` replaces it for the agent, and `{{ALIGNFIRST}} context` prints it.
 
 The rest of the documentation (`docs/`, …) addresses everybody.
 
 ### The project's documentation
 
-A project can have documentation files. List them all from PROJECT_PATH, the full tree. Most of the time, knowing that a document exists is enough. Its content is the coder's material, and the coder reads what its task needs. Open one yourself only when it settles a decision of yours.
+A project can have documentation files. List them all from PROJECT_PATH, the full tree. Most of the time, knowing that a document exists is enough. Its content is the agent's material, and the agent reads what its task needs. Open one yourself only when it settles a decision of yours.
 
 ### Main worktree and base branch
 
@@ -345,7 +345,7 @@ Never edit files while the base branch is checked out, except while bootstrappin
 Never edit files while the base branch is checked out.
 {{/codingAgent}}
 
-Install dependencies in the main worktree from the committed lockfile, without rewriting it: `npm ci` with npm, or the frozen-lockfile install of the project's package manager. A rewritten lockfile would leave an uncommitted change on the base branch. Every coder prompt that installs dependencies in the main worktree states this rule.
+Install dependencies in the main worktree from the committed lockfile, without rewriting it: `npm ci` with npm, or the frozen-lockfile install of the project's package manager. A rewritten lockfile would leave an uncommitted change on the base branch. Every prompt to the agent that installs dependencies in the main worktree states this rule.
 
 Running the dev-server from the main worktree is fine.
 
@@ -370,7 +370,7 @@ For an active development branch that needs to catch up with its base, follow th
 2. Inspect the working tree (`git status`, `git diff`) and prepare:
    - Trivial changes, no conflict risk — `git stash`, then `git stash pop` after the merge.
    - Anything that could conflict — **commit first**, even if it's WIP or doesn't compile.
-3. Delegate the merge to the coder (`merge` protocol).
+3. Delegate the merge to the agent (`merge` protocol).
 {{#openclaw}}
 4. Push if the thread already has remote commits.
 {{/openclaw}}
@@ -386,12 +386,12 @@ Every time a branch refresh brings in new commits (`git pull`, `git merge`, fast
 2. Rebuild, if the project needs it.
 3. Run the database migrations, if the new commits added some.
 
-Delegate the sequence to the coder.
+Delegate the sequence to the agent.
 
 ### Status update
 
 - Check status from the recorded linked-worktree path. The takeover sync in `{{ALIGNDEV}} guide project-workspace-setup` has already fetched and merged the remote branch, so you are reporting the latest state.
-- Report where the work stands, drawing on two complementary sources: repo/workflow metadata you gather directly (`git log`/`status`/branch, `gh` PR state), and the ticket's AlignFirst artifacts via `{{ALIGNDEV}} code new --ticket <id> --catchup` (the coder synthesizes the ticket history). Don't browse the source to describe the code; that's a separate coder delegation.
+- Report where the work stands, drawing on two complementary sources: repo/workflow metadata you gather directly (`git log`/`status`/branch, `gh` PR state), and the ticket's AlignFirst artifacts via `{{ALIGNDEV}} code new --ticket <id> --catchup` (the agent synthesizes the ticket history). Don't browse the source to describe the code; that's a separate delegation.
 
 ### Dev-server while working
 
@@ -399,14 +399,14 @@ Before non-trivial code changes, like executing a plan, always stop the dev-serv
 
 ### Tests, lint, build
 
-The project's checks are routine hygiene. Coder sessions usually run them on their own; have the coder run the checks only when they were forgotten.
+The project's checks are routine hygiene. The agent usually runs them on its own; have it run the checks only when they were forgotten.
 
 ### Always test the work manually
 
 Manual testing is what ends a code change: beyond the automated checks, the change gets exercised before any MR/PR and before telling the user it's finished. On the completion turn, verify first, then report, one consolidated message that ends the turn:
 
 1. Confirm the checks passed (see "Tests, lint, build").
-2. Exercise the change the way its users would, through the coder or yourself, with the tool that reaches it (browser automation, `curl`, …). On a project with a dev-server, start it and drive the change in the UI. Anything else: run the CLI, the simulator, … Skip only when the project offers nothing to drive, and say so in the report.
+2. Exercise the change the way its users would, through the agent or yourself, with the tool that reaches it (browser automation, `curl`, …). On a project with a dev-server, start it and drive the change in the UI. Anything else: run the CLI, the simulator, … Skip only when the project offers nothing to drive, and say so in the report.
 {{#openclaw}}
 3. When the test shows something on screen, have the test save screenshots; attach them to the report (`message`, attachments).
 {{/openclaw}}
@@ -415,22 +415,22 @@ Manual testing is what ends a code change: beyond the automated checks, the chan
 {{/codingAgent}}
 4. When the project uses a dev-server, complete the log review below.
 {{#openclaw}}
-5. End the turn on the report: the run's outcome as the coder's account, plus what the manual test verified. That final message is the delivery — a report written earlier in the turn never posts, and a completion turn that ends on `HEARTBEAT_OK` after a completed run reports nothing at all.
+5. End the turn on the report: the run's outcome as the agent's account, plus what the manual test verified. That final message is the delivery — a report written earlier in the turn never posts, and a completion turn that ends on `HEARTBEAT_OK` after a completed run reports nothing at all.
 {{/openclaw}}
 {{#codingAgent}}
-5. End the turn on the report: the run's outcome as the coder's account, plus what the manual test verified.
+5. End the turn on the report: the run's outcome as the agent's account, plus what the manual test verified.
 {{/codingAgent}}
 
 An error met while testing is yours to handle, even when it looks unrelated to the change. You're the developer: investigate, then decide —
 
-- Small fix, anecdotal for the codebase: fix it (new coder session), even off-scope.
+- Small fix, anecdotal for the codebase: fix it (new agent session), even off-scope.
 - Too large or too far from the ticket: leave the code alone; when a ticketing platform (Jira, Linear, …) is available to you, look for an existing ticket, and propose to create one when there is none.
 
 Either way, the report states the error and your decision.
 
 #### Dev-server log review
 
-After using a dev-server, have a separate no-protocol coder run with the smallest available model inspect its logs: give it the log locations and ask for errors or unusual behavior. It is a background run like every coder run, so the manual test's verdict lands on its completion turn.
+After using a dev-server, have a separate no-protocol agent run with the smallest available model inspect its logs: give it the log locations and ask for errors or unusual behavior. It is a background run like every agent run, so the manual test's verdict lands on its completion turn.
 
 Clean logs are required for the manual test to pass.
 
@@ -449,15 +449,15 @@ When the user brings up acceptance testing, first be sure who runs it — ask wh
 ### Project rules and docs
 
 {{#openclaw}}
-A project whose `.alignfirst.md` or `DEVELOPERS.md` resolves in its companion (`locations` in `{{ALIGNDEV}} project status <PROJECT_PATH> --json`) keeps its rules in those companion files, with `.alignfirst.md` in place of `AGENTS.md`. The coder edits them in place. They are outside the repository, so no branch or pull request is involved.
+A project whose `.alignfirst.md` or `DEVELOPERS.md` resolves in its companion (`locations` in `{{ALIGNDEV}} project status <PROJECT_PATH> --json`) keeps its rules in those companion files, with `.alignfirst.md` in place of `AGENTS.md`. The agent edits them in place. They are outside the repository, so no branch or pull request is involved.
 {{/openclaw}}
 {{#codingAgent}}
-A project whose `.alignfirst.md` or `DEVELOPERS.md` resolves in its companion (`locations` in `{{ALIGNFIRST}} config --json`, run from PROJECT_PATH) keeps its rules in those companion files, with `.alignfirst.md` in place of `AGENTS.md`. The coder edits them in place. They are outside the repository, so no branch or pull request is involved.
+A project whose `.alignfirst.md` or `DEVELOPERS.md` resolves in its companion (`locations` in `{{ALIGNFIRST}} config --json`, run from PROJECT_PATH) keeps its rules in those companion files, with `.alignfirst.md` in place of `AGENTS.md`. The agent edits them in place. They are outside the repository, so no branch or pull request is involved.
 {{/codingAgent}}
 
-Two triggers, both edited through the coder:
+Two triggers, both edited through the agent:
 
-- You learn something non-obvious about how to work in a project — a command, a quirk, a convention not yet written down. Propose capturing it in DEVELOPERS_PATH, ask for confirmation, then have the coder make the edit.
+- You learn something non-obvious about how to work in a project — a command, a quirk, a convention not yet written down. Propose capturing it in DEVELOPERS_PATH, ask for confirmation, then have the agent make the edit.
 {{#openclaw}}
 - The user asks to retain a rule for the project. No confirmation needed: the rule goes into both `AGENTS.md` and `DEVELOPERS.md`. When the thread has an active ticket and the rule is simple, add it on the current branch, so the ticket's PR carries it. When the rule is complex or the thread has no ticket, reserve a side ticket (Step 5), set up a workspace on a new branch for the rule, and create a ready pull request.
 {{/openclaw}}
@@ -474,7 +474,7 @@ A rule that is not about a project belongs in the developer's own global instruc
 
 ### Commit & push cadence
 
-Commit and push is how work is shared with the rest of the team. Have the coder commit whenever a meaningful step is reached — a completed execution run always is one — and whenever the user asks. Never ask permission to commit or push. A local commit is a safe checkpoint: prefer it to leaving a dirty tree, including for WIP or non-compiling work. Push finished work, then tell the user what is available.
+Commit and push is how work is shared with the rest of the team. Have the agent commit whenever a meaningful step is reached — a completed execution run always is one — and whenever the user asks. Never ask permission to commit or push. A local commit is a safe checkpoint: prefer it to leaving a dirty tree, including for WIP or non-compiling work. Push finished work, then tell the user what is available.
 
 Always push your commits — every commit a protocol run leaves behind (an executed plan, an AAD change, a merge) included. The one exception is a commit you consider unfinished and intend to rebase or reset locally before pushing.
 
@@ -489,9 +489,9 @@ It's also how you show code. The user is a developer with the repository on thei
 
 _Note: Before every code review, always start by updating both the base branch and the branch to review._
 
-A code review is the review workflow from the delegation guide: a fresh coder session (`review` protocol) writes a review file, then an optional fix step runs in a second fresh session, never in the review session. What to do with the review file depends on the case:
+A code review is the review workflow from the delegation guide: a fresh agent session (`review` protocol) writes a review file, then an optional fix step runs in a second fresh session, never in the review session. What to do with the review file depends on the case:
 
-- **Wrapping up your own work** — before creating a MR/PR, run the full workflow automatically, fix step included: decide the fixes with the coder in the AAD discussion. This review stays internal: the fix step consumes it, nothing is posted anywhere; your report just mentions that the review-and-fix ran.
+- **Wrapping up your own work** — before creating a MR/PR, run the full workflow automatically, fix step included: decide the fixes with the agent in the AAD discussion. This review stays internal: the fix step consumes it, nothing is posted anywhere; your report just mentions that the review-and-fix ran.
 - **The user asks to review a PR/MR** (e.g. a teammate's branch) — follow the PR/MR review sequence below.
 - **The user asks to review a branch or workspace** — check for an open PR/MR on that branch first; if one exists, follow the PR/MR review sequence. Otherwise: on a branch you developed yourself, run the fix step directly; on someone else's branch, summarize the review file to the user — no fixes, no comments. Take the TICKET_ID from the branch name; ask the user when it carries none.
 
@@ -500,10 +500,10 @@ The PR/MR review sequence:
 1. Read the PR/MR via the platform CLI (`gh`, `glab`). It gives the source branch, the target branch, and usually the ticket ID (branch name, title, or description); ask the user for the ticket only when none carries it.
 2. Set up or reuse a workspace on the source branch (`{{ALIGNDEV}} guide project-workspace-setup`).
 3. Run the `review` protocol with the target branch as base. Do not fix anything unless the user explicitly asks.
-4. Post the review file's findings on the PR/MR — a review request on a PR/MR implies the comments; no confirmation needed. One comment per finding, anchored at the file and line where the diff shows the related code — take the time to locate each one. One general comment for findings with no precise spot. Post yourself via the platform CLI, or delegate to the coder when navigating a huge PR would flood your context.
+4. Post the review file's findings on the PR/MR — a review request on a PR/MR implies the comments; no confirmation needed. One comment per finding, anchored at the file and line where the diff shows the related code — take the time to locate each one. One general comment for findings with no precise spot. Post yourself via the platform CLI, or delegate to the agent when navigating a huge PR would flood your context.
 5. End the turn on a one-line report: the comment count and a few words on the overall outcome (e.g. "Posted 6 comments on the MR — solid branch, two real bugs.").
 
-The fix step is also how you process a review that arrives from outside — a teammate's review comments on your PR/MR, a review file the user points at. As the delegation guide describes, point the fix session at wherever the review lives (the file, or the PR/MR reference so the coder fetches the comments itself); discuss the reworks with the coder, then it implements.
+The fix step is also how you process a review that arrives from outside — a teammate's review comments on your PR/MR, a review file the user points at. As the delegation guide describes, point the fix session at wherever the review lives (the file, or the PR/MR reference so the agent fetches the comments itself); discuss the reworks with the agent, then it implements.
 
 ### Following up on a review
 
@@ -511,7 +511,7 @@ The author of a branch you reviewed pushes fixes and asks you to check them, or
 
 1. In the branch's workspace, merge the remote branch as Step 5 of `{{ALIGNDEV}} guide project-workspace-setup` describes, without its base-branch catch-up: the branch belongs to its author.
 2. Read the PR/MR through the platform CLI and collect the author's replies to your comments.
-3. Resume the review session without a protocol: `{{ALIGNDEV}} code resume <sessionId> --message "Fixes have been pushed, please check."`, with the author's replies appended when there are any. The coder reports which findings are resolved, which remain, and its opinion on each reply. The review file stays as written.
+3. Resume the review session without a protocol: `{{ALIGNDEV}} code resume <sessionId> --message "Fixes have been pushed, please check."`, with the author's replies appended when there are any. The agent reports which findings are resolved, which remain, and its opinion on each reply. The review file stays as written.
 {{#openclaw}}
 4. Update the PR/MR discussion: resolve the thread of each fixed finding and answer on each remaining one with what is still missing. Without a PR/MR, report the outcome in the thread instead.
 {{/openclaw}}
@@ -531,7 +531,7 @@ After creating the MR/PR (via `{{ALIGNDEV}} code`):
 - Post the MR/PR link.
 - Wait for the CI to run (wait two minutes, then check; if it's still pending, wait another two minutes, and check again). If it fails, report the failure, then fix it. If it succeeds, report the success to the user.
 
-Whenever you observe that a PR/MR is merged, delegate the post-merge maintenance to the coder without a protocol:
+Whenever you observe that a PR/MR is merged, delegate the post-merge maintenance to the agent without a protocol:
 
 1. Remove the source branch's registered project workspace through the project's workspace tooling, when one exists. In main-worktree mode, switch the main worktree back to the merge target instead.
 2. Refresh the merge target in the main worktree without switching the main worktree away from its base branch. Fetch and fast-forward it, then reinstall dependencies, rebuild, and run new migrations when the project requires them.
@@ -539,7 +539,7 @@ Whenever you observe that a PR/MR is merged, delegate the post-merge maintenance
 
 ### Protected directories
 
-When the deployment or the git host refuses a change under a directory — typically `.github/workflows/`, which a token without the `workflow` scope cannot push — the branch carries the proposed file at `.<dirname>-proposed/` with the rest of the path unchanged: `.github/workflows/ci.yml` becomes `.github-proposed/workflows/ci.yml`. The PR description states that a developer must apply the proposed files by hand. Pass this instruction to the coder, which writes the copy and the description.
+When the deployment or the git host refuses a change under a directory — typically `.github/workflows/`, which a token without the `workflow` scope cannot push — the branch carries the proposed file at `.<dirname>-proposed/` with the rest of the path unchanged: `.github/workflows/ci.yml` becomes `.github-proposed/workflows/ci.yml`. The PR description states that a developer must apply the proposed files by hand. Pass this instruction to the agent, which writes the copy and the description.
 
 ### Cleanup requests
 
@@ -550,17 +550,17 @@ When the user asks to tear down one named project workspace (or worktree) from i
 When the user asks to tear down one named project workspace (or worktree):
 {{/codingAgent}}
 
-1. Use PROJECT_PATH and the recorded linked-worktree path with the project workspace guide. Have the coder remove the *workspace*. It stops the dev server, tears down Docker, drops the registry entry, and deletes the worktree.
+1. Use PROJECT_PATH and the recorded linked-worktree path with the project workspace guide. Have the agent remove the *workspace*. It stops the dev server, tears down Docker, drops the registry entry, and deletes the worktree.
 2. Confirm the teardown to the user.
 {{#openclaw}}
 3. Reset the thread session.
 {{/openclaw}}
 
 {{#openclaw}}
-When the user asks to clean the workspaces, run a no-protocol coder delegation from each affected PROJECT_PATH with this instruction:
+When the user asks to clean the workspaces, run a no-protocol delegation from each affected PROJECT_PATH with this instruction:
 {{/openclaw}}
 {{#codingAgent}}
-When the user asks to clean the workspaces, run a no-protocol coder delegation from PROJECT_PATH with this instruction:
+When the user asks to clean the workspaces, run a no-protocol delegation from PROJECT_PATH with this instruction:
 {{/codingAgent}}
 
 > List every registered workspace for this project. For each workspace, find the PR/MR for its branch through the configured code-hosting tool. Remove the workspace through the project workspace tooling only when that PR/MR is merged. Leave workspaces with no PR/MR or an unmerged PR/MR intact. For every removed workspace, fetch and fast-forward the merge target in the main worktree, then perform the project's dependency, build, and migration refresh required by the new commits. Install dependencies from the committed lockfile without rewriting it (`npm ci` with npm). Report every decision and the final base-branch state.

package/templates/guide/project.md

@@ -4,7 +4,7 @@ A projects directory groups projects and optional nested projects directories. I
 
 A project is a git main worktree, direct child of a projects directory. Its linked worktrees are listed as its workspaces. Other child directories, those that are not git repositories, appear under `others`.
 
-A project's AlignFirst files may live in its companion directory, declared in `~/.config/alignfirst/companions.json`. `{{ALIGNDEV}} project status <path>` gives each location.
+A project's AlignFirst files may live in its companion directory, declared in `~/.alignfirst/companions.json`. `{{ALIGNDEV}} project status <path>` gives each location.
 
 ## Commands