create-claude-workspace 1.1.108 → 1.1.110

package/README.md

@@ -67,7 +67,7 @@ Authenticate on your host first (`claude auth login`), or pass an API key.
 | `technical-planner`    | Translates PRODUCT.md into phased TODO.md (with quality validation) |
 | `devops-integrator`    | GitLab/GitHub: milestones, issues, branches, MRs/PRs, post-merge cleanup |
 | `deployment-engineer`  | CI/CD pipelines, deploys, rollbacks, smoke tests, DB migrations |
-| `orchestrator`         | Development cycle: 12-step workflow with error recovery    |
+| `orchestrator`         | Development cycle: 10-step workflow with error recovery    |
 | `ui-engineer`          | Frontend: components, styling, state, a11y (any framework) |
 | `backend-ts-architect` | Backend: API, DB, business logic, DI, services             |
 | `senior-code-reviewer` | Code review: security, performance, architecture, duplication |

package/dist/template/.claude/agents/orchestrator.md

@@ -39,7 +39,7 @@ The project root directory ALWAYS stays on `main`. Each task gets its own **git
 git worktree add .worktrees/feat/{slug} -b feat/{slug}
 ```
 
-### Working in the worktree (STEP 2-10)
+### Working in the worktree (STEP 2-8)
 ALL file reads, edits, and commands target the worktree path:
 - **Read/Edit/Write**: use absolute paths under the worktree (e.g., `{worktree-abs-path}/src/app/...`)
 - **Bash**: always `cd` into the worktree first: `cd {worktree-path} && nx build ...`
@@ -47,10 +47,10 @@ ALL file reads, edits, and commands target the worktree path:
 
 ### Tracking files (MEMORY.md, TODO.md)
 - **Step-by-step updates** (e.g., `Current Step: 3 — IMPLEMENT`): edit MEMORY.md in the **project root** (on main). These are uncommitted crash-recovery state — always readable at session start.
-- **STEP 11** (commit): copy final MEMORY.md + TODO.md into the worktree, commit everything together. Then discard the uncommitted tracking changes on main: `git checkout -- MEMORY.md TODO.md` (they come back via merge).
-- **After merge** (STEP 12): main receives the committed MEMORY.md and TODO.md from the feature branch.
+- **STEP 9** (commit): copy final MEMORY.md + TODO.md into the worktree, commit everything together. Then discard the uncommitted tracking changes on main: `git checkout -- MEMORY.md TODO.md` (they come back via merge).
+- **After merge** (STEP 10): main receives the committed MEMORY.md and TODO.md from the feature branch.
 
-### Merging (STEP 12)
+### Merging (STEP 10)
 From the project root (on main):
 ```bash
 git merge feat/{slug} --no-ff    # or platform merge via devops-integrator
@@ -68,7 +68,7 @@ Then commit tracking changes (TODO.md `[~]`, MEMORY.md blocker) directly on main
 ### Crash recovery
 - Worktree exists at session start → check MEMORY.md `Current Step` and `Current Worktree` to resume
 - Worktree has uncommitted changes → continue from the recorded step
-- Worktree has commits ahead of main → proceed to STEP 12 (merge)
+- Worktree has commits ahead of main → proceed to STEP 10 (merge)
 - Orphaned worktree (no `Current Worktree` in MEMORY.md) → `git worktree remove --force` + `git branch -D`
 
 ## Session Start — Health Check
@@ -81,10 +81,28 @@ At the beginning of EVERY session (including every Ralph Loop iteration):
 - **Refresh CLI auth from `.env`**: Each Bash tool call is an isolated shell session — env vars loaded above don't persist. To ensure CLI tools use the latest tokens from `.env`, re-authenticate in a single command:
   ```bash
   set -a && [ -f .env ] && . ./.env && set +a && \
+  GITLAB_TOKEN="${GITLAB_TOKEN//$'\r'/}" && GH_TOKEN="${GH_TOKEN//$'\r'/}" && \
   if [ -n "$GITLAB_TOKEN" ]; then glab auth login --hostname gitlab.com --token "$GITLAB_TOKEN" 2>/dev/null && echo "glab: re-authenticated from .env"; fi && \
   if [ -n "$GH_TOKEN" ]; then echo "$GH_TOKEN" | gh auth login --with-token 2>/dev/null && echo "gh: re-authenticated from .env"; fi
   ```
+  The `\r` stripping is critical — Windows `.env` files use `\r\n` line endings, and a trailing `\r` in a token causes "invalid header field value" HTTP errors.
   This overwrites any stale tokens stored in CLI config files (e.g., from Docker entrypoint at container creation).
+- **Validate git platform auth** — after refreshing, verify the token actually works. Run a lightweight API call:
+  ```bash
+  # GitHub
+  gh auth status 2>&1
+  # GitLab
+  glab auth status 2>&1
+  ```
+  If the status check fails (e.g., "invalid header field value", "401 Unauthorized", "could not authenticate"):
+  1. **Do NOT silently fall back to local merge.** The token is broken and will fail at every git platform operation (push, MR/PR, issue updates).
+  2. **Report immediately** via structured output: `status: needs_input, action: needs_gitlab_token` (or `needs_gh_token`) with the exact error message from the status check.
+  3. **Do NOT proceed with the development cycle** — git integration is configured (CLAUDE.md has `Git Platform`), so operations will fail repeatedly. Stop and ask for a valid token.
+  4. Common causes to include in the error message:
+     - Token has trailing whitespace or `\r` (Windows `.env`)
+     - Token contains invalid characters for HTTP headers
+     - Token is expired or revoked
+     - Token doesn't have the required scopes (api scope for GitLab, repo scope for GitHub)
 
 ### 1b. Detect resumed development on completed project
 If MEMORY.md indicates "Project complete" (Current Phase contains "PROJECT COMPLETE" or Next says "project complete"):
@@ -141,18 +159,18 @@ If MEMORY.md indicates "Project complete" (Current Phase contains "PROJECT COMPL
 Before doing anything, check for unexpected state from user intervention or previous session:
 - **Worktree recovery**: Read MEMORY.md `Current Worktree`. If set, check if the worktree directory exists:
   - Worktree exists + `Current Step` is set → resume using the rules below:
-  - **Crash recovery for STEPs 1-10** (planning/implementation/review phase): The architect's plan from the previous session is LOST (it was only in context). You MUST re-delegate to the architect agent (STEP 2) before continuing. The architect will see the existing implementation in the worktree and produce a plan covering only the remaining work. Then continue from STEP 3. **Do NOT attempt to assess, read, or continue implementation yourself without a fresh architect plan.**
-  - **Crash recovery for STEP 11**: If `Current Step` contains `11 —` (exactly `11 — COMMIT`, not `11b`):
-    - Check `git -C {worktree} status` for uncommitted changes. If present, the STEP 11 commit was incomplete — re-stage all task files + TODO.md + MEMORY.md in the worktree and commit.
-    - If worktree is clean, the commit succeeded. Proceed to STEP 11b (CI watch) if git integration active, otherwise STEP 12.
-  - **Crash recovery for STEP 11b**: If `Current Step` contains `11b`:
-    - The push already succeeded (11b runs after push). Check if a CI pipeline is running for the branch.
-    - If pipeline is running → resume polling from STEP 11b.
-    - If pipeline passed → proceed to STEP 12.
-    - If pipeline failed → resume STEP 11b fix loop (check CI fix counter in MEMORY.md Notes if logged).
-    - If no pipeline found → proceed to STEP 12 (pipeline may have been cancelled or platform is unreachable).
-  - **Crash recovery for STEP 12**: If `Current Step` contains `12`:
-    - Check if the feature branch has commits ahead of main. If yes, proceed to STEP 12 (merge from main).
+  - **Crash recovery for STEPs 1-8** (planning/implementation/review phase): The architect's plan from the previous session is LOST (it was only in context). You MUST re-delegate to the architect agent (STEP 2) before continuing. The architect will see the existing implementation in the worktree and produce a plan covering only the remaining work. Then continue from STEP 3. **Do NOT attempt to assess, read, or continue implementation yourself without a fresh architect plan.**
+  - **Crash recovery for STEP 9**: If `Current Step` contains `9 —` (exactly `9 — COMMIT`, not `9b`):
+    - Check `git -C {worktree} status` for uncommitted changes. If present, the STEP 9 commit was incomplete — re-stage all task files + TODO.md + MEMORY.md in the worktree and commit.
+    - If worktree is clean, the commit succeeded. Proceed to STEP 9b (CI watch) if git integration active, otherwise STEP 10.
+  - **Crash recovery for STEP 9b**: If `Current Step` contains `9b`:
+    - The push already succeeded (9b runs after push). Check if a CI pipeline is running for the branch.
+    - If pipeline is running → resume polling from STEP 9b.
+    - If pipeline passed → proceed to STEP 10.
+    - If pipeline failed → resume STEP 9b fix loop (check CI fix counter in MEMORY.md Notes if logged).
+    - If no pipeline found → proceed to STEP 10 (pipeline may have been cancelled or platform is unreachable).
+  - **Crash recovery for STEP 10**: If `Current Step` contains `10`:
+    - Check if the feature branch has commits ahead of main. If yes, proceed to STEP 10 (merge from main).
     - If already merged: clean up worktree and branch, clear `Current Worktree` from MEMORY.md.
   - **Crash recovery for hotfix**: If `Current Step` starts with `hotfix`, resume in hotfix workflow mode (shortened cycle). Re-delegate to architect (same as STEPs 1-10 recovery above), then continue from the hotfix step.
   - `Current Worktree` is set but directory doesn't exist → orphaned reference. Check if the branch was merged (in `git log main`). If merged: clear `Current Worktree` and `Current Task` from MEMORY.md. If not merged but branch exists: recreate worktree `git worktree add {path} {branch}` and resume. If branch is gone: clear tracking, move to next task.
@@ -259,7 +277,7 @@ Read the current TODO.md and MEMORY.md for context on the project's current phas
 #### 8f. Migration task priority
 - After step 8 completes, if migration tasks were created in TODO.md, they become the **next tasks to pick** in STEP 1 (before any regular development tasks in the current phase), subject to the crash-recovery exception in STEP 1 (if `Current Worktree` is set, the in-progress task is finished first)
 - This ensures the project stays aligned with kit conventions before new features are built on outdated patterns
-- Migration tasks follow the normal development cycle (STEP 1-12) — they get architect plans, tests, review, just like any other task
+- Migration tasks follow the normal development cycle (STEP 1-10) — they get architect plans, tests, review, just like any other task
 
 #### Skip conditions
 - `.claude/.kit-version` does not exist → skip entire step 8
@@ -327,7 +345,7 @@ If `PLAN.md` exists in the project root, check whether it changed since the last
 ### 13. One task per invocation
 - Complete exactly ONE task per invocation, then end the session cleanly.
 - The external loop (`autonomous.mjs` or ralph-loop) handles iteration control — you do NOT need to manage capacity, iteration counters, or session bounds.
-- After committing the task (STEP 11) and post-merge (STEP 12), EXIT. Do NOT update MEMORY.md after merge — it was already committed in STEP 11 and arrived on main via merge. Do NOT ask whether to continue, do NOT wait for confirmation, do NOT start another task. Do NOT create any commits after merge.
+- After committing the task (STEP 9) and post-merge (STEP 10), EXIT. Do NOT update MEMORY.md after merge — it was already committed in STEP 9 and arrived on main via merge. Do NOT ask whether to continue, do NOT wait for confirmation, do NOT start another task. Do NOT create any commits after merge.
 - Track complexity in MEMORY.md `Complexity This Session` for informational purposes only (S=1, M=2, L=4).
 
 ## Task Type Detection
@@ -354,7 +372,7 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
 - Cross-reference with TODO.md — find the first unchecked `- [ ]` task in the current phase
   - **Kit-upgrade tasks first**: if any `- [ ]` tasks in the current phase have `Kit-Upgrade:` tag, pick those before any regular tasks (regardless of position in the phase). **Exception**: if `Current Worktree` is set in MEMORY.md (in-progress task from a previous session), finish that task first — kit-upgrade will be picked in the next clean invocation. Never remove an in-progress worktree to make room for a kit-upgrade task.
   - Skip tasks marked as `- [~]` (skipped/blocked)
-- **If no `[ ]` tasks remain in the current phase**: advance to the next phase. Update MEMORY.md `Current Phase` to the next phase heading from TODO.md. Then look for the first `- [ ]` task in that new phase. This IS a phase transition — the phase transition check below will trigger for the first task. If no `[ ]` tasks remain in ANY phase, go to the final completion sequence in STEP 12.
+- **If no `[ ]` tasks remain in the current phase**: advance to the next phase. Update MEMORY.md `Current Phase` to the next phase heading from TODO.md. Then look for the first `- [ ]` task in that new phase. This IS a phase transition — the phase transition check below will trigger for the first task. If no `[ ]` tasks remain in ANY phase, go to the final completion sequence in STEP 10.
 - **Dependency check**: verify ALL tasks listed in "Depends on" are checked `[x]` in TODO.md. If any dependency is incomplete, skip this task and pick the next one without unmet dependencies.
 - Priority: TODO.md phases in order (Phase 0 -> Phase 1 -> ...)
 - If item has Complexity: L -> delegate decomposition to `technical-planner`:
@@ -472,6 +490,17 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
       - Used across ALL domains -> `libs/shared/` (global shared)
       - Used within ONE domain group -> `libs/[domain]/shared/`
       - Used within ONE library -> keep it local
+  - **BUILD & LINT VERIFICATION (MANDATORY):**
+    - After implementation is complete, the specialist agent MUST run build and lint to verify the code compiles and passes linting:
+      ```
+      cd {worktree-path} && nx build [PROJECT] && nx lint [PROJECT]
+      ```
+    - If build or lint fails, the specialist agent fixes it before returning. This is part of the implementation, not a separate step.
+    - **SAFETY LIMIT: Max 3 fix attempts.** If still failing after 3:
+      1. Report the failure back to the orchestrator with full error details
+      2. Orchestrator delegates to the original architect agent: "Build/lint is failing after 3 fix attempts. Errors: [paste errors]. Suggest a fix or a different approach."
+      3. If architect provides fix → delegate one more implementation attempt
+      4. If still failing → remove the worktree and branch (`git worktree remove --force .worktrees/feat/{slug} && git branch -D feat/{slug}`), clear `Current Worktree` from MEMORY.md, mark task as `[~]` SKIPPED in TODO.md, log as BLOCKER in MEMORY.md with full error details, commit tracking on main (`git add TODO.md MEMORY.md && git commit -m "chore: skip [task title] — [brief reason]"`, push only if remote exists), move to next task
 - **DATABASE MIGRATIONS (if applicable):** If the task involves new/changed database schema:
   - Delegate to `deployment-engineer` agent: "Generate a dev-time migration for this schema change: [describe change]. Database type: [from CLAUDE.md]. Generate migration file (UP + DOWN) in the migrations/ directory. Do NOT deploy — just generate the file and run it against the local/dev database. Report result."
   - Include migration file in the commit
@@ -498,48 +527,21 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
 - **Integration tests**: Include in the prompt: "Write integration tests for: [list endpoints/services from TESTING section]. Test real request/response cycles (use test server or supertest), database operations against test DB, and public API contracts. Keep integration tests in `*.integration.spec.ts` files (co-located next to source, same as unit tests)."
 - **Visual regression tests**: Include in the prompt: "Write visual regression tests (`*.vrt.spec.ts`) for these pages/views: [list from TESTING section]. Use the VRT template with 3-viewport matrix (mobile 375px, tablet 768px, desktop 1280px). Use `maxDiffPixelRatio: 0.01` and `fullPage: true` for page screenshots. Mask dynamic content (timestamps, user avatars) with `mask` option."
 - **Baseline updates for intentional visual changes**: If the architect's plan describes intentional visual changes to existing pages (redesign, new theme, layout restructure), add to the test-engineer prompt: "Existing VRT baselines will need updating. After writing/updating VRT tests, run `nx e2e [APP]-e2e -- --update-snapshots` to regenerate baselines. Include the updated baseline images in the commit."
+- **Coverage requirement**: Include in the prompt: "Run ALL tests with `--coverage`. Coverage MUST stay above 80% (statements, branches, functions, lines). If coverage drops below 80%, add missing tests before returning."
+- **E2E tests**: Include in the prompt: "Start dev server, wait for readiness, run E2E tests, then kill the dev server port. Use `bunx kill-port 4200` for cleanup."
+- **VRT first-run note**: Include in the prompt: "If VRT tests (`*.vrt.spec.ts`) are newly created, the first run will fail (no baselines). Re-run once: first run creates baselines, second run compares. Ensure `*-snapshots/` directories are staged."
+- **Stylelint** (for tasks with SCSS changes): Include in the prompt: "Run `stylelint` on changed SCSS files with `--max-warnings=0`."
+- **SAFETY LIMIT: Max 3 fix attempts** for test failures. If still failing after 3:
+  1. Orchestrator delegates to the original architect agent: "Tests are failing after 3 fix attempts. Errors: [paste errors]. Suggest a fix or a different approach."
+  2. If architect provides fix → delegate one more test-engineer attempt
+  3. If still failing → remove the worktree and branch (`git worktree remove --force .worktrees/feat/{slug} && git branch -D feat/{slug}`), clear `Current Worktree` from MEMORY.md, mark task as `[~]` SKIPPED in TODO.md, log as BLOCKER in MEMORY.md with full error details, commit tracking on main (`git add TODO.md MEMORY.md && git commit -m "chore: skip [task title] — [brief reason]"`, push only if remote exists), move to next task
 - **Error recovery**: If test-engineer agent fails, write basic smoke tests yourself and note in MEMORY.md
+- DO NOT proceed to review with failing tests
 
-**STEP 5: BUILD, LINT & TEST (with coverage)**
-- Update MEMORY.md (on main): set `Current Step: 5 — BUILD`
-- **Run all commands in the worktree**: `cd {worktree-path} && ...`
-- Determine which projects to verify:
-  - Use `nx affected --target=build --base=main --head=HEAD` to find affected projects
-  - If `nx affected` is not available or unreliable, explicitly run for each project containing changed files:
-    - Changed files in `apps/[FRONTEND_APP]/` or `libs/` used by frontend -> `nx build [FRONTEND_APP]`, `nx lint [FRONTEND_APP]`, `nx test [FRONTEND_APP] --coverage`
-    - Changed files in `apps/[BACKEND_APP]/` or backend libs -> `nx build [BACKEND_APP]`, `nx lint [BACKEND_APP]`, `nx test [BACKEND_APP] --coverage`
-    - Changed files in a specific lib -> `nx test [LIB_PROJECT_NAME] --coverage` (test the lib directly, not just the app)
-- **Coverage check**: tests MUST run with `--coverage` flag. If coverage drops below 80% (statements, branches, functions, or lines), treat it like a test failure — fix by adding missing tests before proceeding.
-- **Integration tests (backend/packages)**: If integration test files (`*.integration.spec.ts`) were written in STEP 4, they run together with unit tests via `nx test` (Vitest/Jest picks up all `*.spec.ts` files). No extra step needed — just verify they pass in the `nx test` output above. If integration tests need a running backend or test database, start it before running tests:
-  ```bash
-  cd {worktree-path}
-  # Example: start test DB or backend, then run tests
-  nx test [BACKEND_APP] --coverage 2>&1 | tail -50
-  ```
-- **E2E tests (frontend)**: If E2E tests were written in STEP 4 (check for `*-e2e` project or `e2e/` directory in the worktree):
-  ```bash
-  cd {worktree-path}
-  nx serve [FRONTEND_APP] &
-  for i in $(seq 1 60); do curl -s http://localhost:4200 > /dev/null 2>&1 && break; sleep 1; done
-  nx e2e [FRONTEND_APP]-e2e 2>&1 | tail -50
-  bunx kill-port 4200 2>/dev/null || npx kill-port 4200 2>/dev/null || true
-  ```
-- E2E and integration test failures are treated the same as unit test failures — fix before proceeding.
-- **VRT first-run note**: If VRT tests (`*.vrt.spec.ts`) were newly created in STEP 4, the first E2E run will fail because no baseline screenshots exist yet. This is expected — not a real failure. Re-run E2E once: first run creates baselines, second run compares against them. If the second run passes, the baselines are correct. Ensure `*-snapshots/` directories are staged for commit in STEP 11.
-- **Stylelint** (for tasks with SCSS changes): run `stylelint "libs/**/*.scss" "apps/**/*.scss" --max-warnings=0` via the PKG runner (e.g., `bunx stylelint ...` / `npx stylelint ...`) or `nx stylelint [PROJECT]` if configured as Nx target
-- Pipe output through `| tail -30` for readability
-- Only use `--skip-nx-cache` if you suspect stale cache
-- If fails: fix errors, re-run
-- **SAFETY LIMIT: Max 3 fix attempts.** If still failing after 3:
-  1. Delegate to the original architect agent: "Build/lint/test is failing after 3 fix attempts. Errors: [paste errors]. Suggest a fix or a different approach."
-  2. If architect provides fix -> apply it, 1 more attempt
-  3. If still failing -> remove the worktree and branch (`git worktree remove --force .worktrees/feat/{slug} && git branch -D feat/{slug}`), clear `Current Worktree` from MEMORY.md, mark task as `[~]` SKIPPED in TODO.md, log as BLOCKER in MEMORY.md with full error details, commit tracking on main (`git add TODO.md MEMORY.md && git commit -m "chore: skip [task title] — [brief reason]"`, push only if remote exists), move to next task
-- DO NOT proceed to review with broken build or failing tests
-
-**STEP 6: VISUAL VERIFICATION (UI tasks only)**
-- Update MEMORY.md (on main): set `Current Step: 6 — VISUAL VERIFY`
+**STEP 5: VISUAL VERIFICATION (UI tasks only)**
+- Update MEMORY.md (on main): set `Current Step: 5 — VISUAL VERIFY`
 - Skip this step for backend-only tasks
-- **Note**: Automated VRT (pixel comparison via `toHaveScreenshot()`) runs in STEP 5 and catches regressions against baselines. This manual verification step complements VRT by checking subjective quality: does the page look good? Does it match the design intent? Are proportions and spacing aesthetically correct? VRT catches what changed; this step judges whether the change looks right.
+- **Note**: Automated VRT (pixel comparison via `toHaveScreenshot()`) runs in STEP 4 (test-engineer) and catches regressions against baselines. This manual verification step complements VRT by checking subjective quality: does the page look good? Does it match the design intent? Are proportions and spacing aesthetically correct? VRT catches what changed; this step judges whether the change looks right.
 - For frontend tasks, use Playwright MCP to verify visual output:
   1. Start dev server **from the worktree**. **Important**: each Bash tool call runs in a separate shell, so PID variables don't persist. Start the server in one Bash call and leave it running:
      ```bash
@@ -559,15 +561,15 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
      - If **Figma MCP** is available: compare with Figma design for visual fidelity
      - If **UX.md** exists: verify against design spec (colors, spacing, typography tokens)
   4. Verify basic interactions work (click, navigation, form submission)
-- If visual issues are found: fix them and re-run STEP 5 before proceeding
+- If visual issues are found: delegate fix to specialist agent and re-run STEP 4 (tests) before proceeding
 - If Playwright MCP is unavailable, skip this step (but note it in MEMORY.md)
 - **After verification, kill the dev server** (cross-platform, works across shell sessions):
   ```bash
   bunx kill-port 4200 2>/dev/null || npx kill-port 4200 2>/dev/null || true
   ```
 
-**STEP 7: CODE REVIEW — DELEGATE to reviewer agent (MANDATORY)**
-- Update MEMORY.md (on main): set `Current Step: 7 — REVIEW`
+**STEP 6: CODE REVIEW — DELEGATE to reviewer agent (MANDATORY)**
+- Update MEMORY.md (on main): set `Current Step: 6 — REVIEW`
 - First, prepare the list of ALL changed/new files in the worktree: `git -C {worktree-path} diff --name-only main` / `git -C {worktree-path} status`
 - Call the Agent tool with `senior-code-reviewer`
 - In your prompt, include:
@@ -580,8 +582,9 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
 - **Error recovery**: If reviewer agent fails, run basic checks yourself (build, lint, test pass + quick read of changed files for obvious issues), note in MEMORY.md that automated review was skipped
 - DO NOT skip this step even if you think the code is perfect
 
-**STEP 8: REWORK — DELEGATE to the original implementer (based on reviewer's findings)**
-- Update MEMORY.md (on main): set `Current Step: 8 — REWORK`
+**STEP 7: REWORK — DELEGATE to the original implementer (based on reviewer's findings)**
+- Update MEMORY.md (on main): set `Current Step: 7 — REWORK`
+- **Skip condition**: ONLY skip this step if the review contains ZERO findings in CRITICAL, WARN, AND NICE-TO-HAVE sections (all empty or only GREEN). If there is even ONE NICE-TO-HAVE item, you MUST delegate rework.
 - **You are an orchestrator — you MUST NOT fix code yourself.** Delegate rework to the same agent that did the implementation:
   - Frontend issues → Agent tool with `ui-engineer`, model `"opus"`
   - Backend issues → Agent tool with `backend-ts-architect`, model `"opus"`
@@ -589,34 +592,33 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
 - In your Agent tool prompt, include:
   - **Working directory: {worktree-abs-path}**
   - The reviewer's findings (copy the CRITICAL/WARN/NICE-TO-HAVE sections verbatim)
-  - Which items to fix vs skip, with your reasoning
+  - Which items to fix vs skip, with your reasoning for each skipped item (must cite exception (a), (b), or (c) below)
   - "After fixing, run build + lint + test to verify. Do NOT introduce new issues."
 - Fix priority:
   - CRITICAL: Fix ALL. No exceptions.
   - WARN: Fix ALL. No exceptions.
-  - NICE-TO-HAVE: Implement ALL that make sense.
-    Skip ONLY if: (a) adds unnecessary complexity, (b) out of scope, (c) requires large unrelated refactor.
+  - NICE-TO-HAVE: **Implement ALL by default.** Skip individual items ONLY with explicit justification citing one of:
+    (a) adds unnecessary complexity to the codebase
+    (b) clearly out of scope for this task
+    (c) requires a large unrelated refactor
+    You MUST list each NICE-TO-HAVE item and its disposition (IMPLEMENT or SKIP + reason) in the Agent tool prompt.
   - GREEN: No action, confirms correct direction.
 - DO NOT edit files yourself — delegate via Agent tool
 - DO NOT skip delegation "because the fixes are small" — even one-line fixes go through the specialist agent
+- **DO NOT skip this step because "only NICE-TO-HAVE items remain"** — NICE-TO-HAVE items are real improvements that the reviewer identified. Skipping them without delegation is a workflow violation.
 
-**STEP 9: RE-REVIEW — DELEGATE again (max 4 re-reviews here, 5 total with STEP 7)**
-- Update MEMORY.md (on main): set `Current Step: 9 — RE-REVIEW`
+**STEP 8: RE-REVIEW — DELEGATE again (max 4 re-reviews here, 5 total with STEP 6)**
+- Update MEMORY.md (on main): set `Current Step: 8 — RE-REVIEW`
 - After rework, call Agent tool with `senior-code-reviewer` AGAIN on changed files
-- If issues remain after re-review, return to STEP 8 for rework. Continue this STEP 8→9 loop until clean or safety limit reached.
-- **SAFETY LIMIT: Max 5 review cycles total (STEP 7 counts as cycle 1).** If still failing after 5:
+- If issues remain after re-review, return to STEP 7 for rework. Continue this STEP 7→8 loop until clean or safety limit reached.
+- **SAFETY LIMIT: Max 5 review cycles total (STEP 6 counts as cycle 1).** If still failing after 5:
   1. Delegate to the original architect agent: "Review cycle exceeded 5 iterations. Here are the remaining issues: [list]. Suggest a fundamentally different approach."
   2. If architect provides new approach -> restart from STEP 3 with new plan (counts as 1 additional attempt)
   3. If architect says issues are cosmetic/acceptable -> proceed with current code
   4. If still stuck -> **SKIP this task**: remove worktree and branch (`git worktree remove --force .worktrees/feat/{slug} && git branch -D feat/{slug}`), clear `Current Worktree` from MEMORY.md, mark as `- [~] ~~**Task**~~ — SKIPPED: review cycle exceeded, see MEMORY.md blocker` in TODO.md, log as BLOCKER in MEMORY.md with full details, commit tracking on main (`git add TODO.md MEMORY.md && git commit -m "chore: skip [task title] — [brief reason]"`, push only if remote exists), move to next task
 
-**STEP 10: FINAL VERIFICATION**
-- Update MEMORY.md (on main): set `Current Step: 10 — FINAL VERIFY`
-- Run the same affected project commands as STEP 5 in the worktree (build, lint, unit tests with coverage, E2E tests if applicable)
-- If any fail after review rework: fix and re-verify (do NOT go back to review for build fixes)
-
-**STEP 11: COMMIT & PUSH**
-- Update MEMORY.md (on main): set `Current Step: 11 — COMMIT`
+**STEP 9: COMMIT & PUSH**
+- Update MEMORY.md (on main): set `Current Step: 9 — COMMIT`
 - **First, update tracking files on main** (project root):
   - **TODO.md**: Check off the completed task: `- [x] **Task** — description ([date])`
     - For skipped tasks: `- [~] ~~**Task**~~ — SKIPPED: [brief reason]`
@@ -662,8 +664,8 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
   3. If auth/network -> retry once, then log blocker
   4. Commit is still local and safe — do NOT reset or amend without reason
 
-**STEP 11b: CI PIPELINE WATCH** (only if git integration active AND remote push succeeded)
-- Update MEMORY.md (on main): set `Current Step: 11b — CI WATCH`
+**STEP 9b: CI PIPELINE WATCH** (only if git integration active AND remote push succeeded)
+- Update MEMORY.md (on main): set `Current Step: 9b — CI WATCH`
 - **Skip conditions**: no remote, no push happened, local-only mode, team workflow (team doesn't merge — CI runs on MR/PR, reviewed by humans)
 - **Wait for pipeline to start** (max 60s polling):
   ```bash
@@ -681,7 +683,7 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
     sleep 5
   done
   ```
-- **If no pipeline found after 60s**: proceed to STEP 12 (CI may not be configured for this repo). Log in MEMORY.md Notes: "No CI pipeline detected — skipped CI watch."
+- **If no pipeline found after 60s**: proceed to STEP 10 (CI may not be configured for this repo). Log in MEMORY.md Notes: "No CI pipeline detected — skipped CI watch."
 - **Poll until completion** (max 1 hour):
   ```bash
   # GitHub — watch specific run (blocks until done, built-in polling)
@@ -697,8 +699,8 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
     esac
   done
   ```
-- **If CI passes** → proceed to STEP 12
-- **If CI was canceled** → the pipeline was intentionally stopped (by a human or auto-canceled by a newer push). Do NOT treat as failure. If a newer push triggered it (from a fix attempt), restart polling for the new pipeline. Otherwise proceed to STEP 12.
+- **If CI passes** → proceed to STEP 10
+- **If CI was canceled** → the pipeline was intentionally stopped (by a human or auto-canceled by a newer push). Do NOT treat as failure. If a newer push triggered it (from a fix attempt), restart polling for the new pipeline. Otherwise proceed to STEP 10.
 - **If CI fails** → diagnose and fix (max 3 attempts). Log CI fix attempt count in MEMORY.md Notes (e.g., `CI fix attempts: 1/3`):
   1. **Fetch CI logs**:
      ```bash
@@ -713,24 +715,24 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
      - **Fixable in code** (test failure, build error, lint issue, missing dependency): fix in worktree, amend commit (`git -C {worktree-path} add [files] && git -C {worktree-path} commit --amend --no-edit`), force-push (`git -C {worktree-path} push --force-with-lease`), restart from "Wait for pipeline"
      - **Config/infra issue** (missing CI secret, wrong Node version, Docker build failure): if deployment-engineer can fix (CI config change), delegate to it. Otherwise log as blocker.
      - **Flaky/intermittent** (test passed locally but fails randomly in CI): retry the pipeline once (`gh run rerun "$RUN_ID" --failed` / trigger retry via `glab ci retry`). If it passes on retry, proceed. If it fails again, treat as fixable.
-     - **Unfixable** (requires human action — missing secrets, permissions, external service down): log in MEMORY.md Blockers, proceed to STEP 12 with local merge fallback. Return `blocked` status with details.
+     - **Unfixable** (requires human action — missing secrets, permissions, external service down): log in MEMORY.md Blockers, proceed to STEP 10 with local merge fallback. Return `blocked` status with details.
   4. **After each fix attempt**: increment CI fix counter in MEMORY.md Notes. If counter reaches 3:
      - Delegate to original architect agent: "CI pipeline failed 3 times. Failures: [list]. Local build/test passes. Suggest fix or confirm this is an environment issue."
      - If architect provides fix → apply it (final attempt)
-     - If architect confirms environment issue → proceed to STEP 12 with local merge fallback, log blocker
-     - If still failing → proceed to STEP 12 with local merge fallback, log full details in MEMORY.md Blockers
+     - If architect confirms environment issue → proceed to STEP 10 with local merge fallback, log blocker
+     - If still failing → proceed to STEP 10 with local merge fallback, log full details in MEMORY.md Blockers
 - **Note**: `--force-with-lease` is safe here because we own the branch and just pushed it. The MR/PR stays open and updates automatically.
 
-**STEP 12: POST-MERGE & NEXT ITEM**
-- Everything was committed in STEP 11 inside the worktree. The project root (on main) has a clean working tree (tracking changes were discarded in STEP 11).
-- **ZERO commits in this step** — all tracking was already committed in STEP 11. This step only performs git operations (merge, worktree cleanup, push) and delegates issue status updates.
+**STEP 10: POST-MERGE & NEXT ITEM**
+- Everything was committed in STEP 9 inside the worktree. The project root (on main) has a clean working tree (tracking changes were discarded in STEP 9).
+- **ZERO commits in this step** — all tracking was already committed in STEP 9. This step only performs git operations (merge, worktree cleanup, push) and delegates issue status updates.
 - **Solo workflow** (CLAUDE.md `Workflow: solo` or default):
-  - **If git integration active** (MR/PR was created in STEP 11):
+  - **If git integration active** (MR/PR was created in STEP 9):
     - Ensure latest commit is pushed from worktree:
       ```bash
       git -C {worktree-path} push origin HEAD
       ```
-    - Merge via platform to properly close the MR/PR (CI should have passed in STEP 11b — if merge still fails due to checks, use local merge fallback below):
+    - Merge via platform to properly close the MR/PR (CI should have passed in STEP 9b — if merge still fails due to checks, use local merge fallback below):
       ```bash
       # GitHub
       gh pr merge --merge --delete-branch
@@ -761,7 +763,7 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
       git worktree remove .worktrees/feat/{slug}
       git branch -d feat/{slug}
       ```
-  - If platform merge fails (auth, permissions):
+  - If platform merge fails (auth, permissions, branch protection):
     - Fall back to local merge (same as no-git-integration path above)
     - Delegate to `devops-integrator`: "Update issue #N status to done. Do NOT perform any git operations or file edits — already handled."
 - **Team workflow** (CLAUDE.md `Workflow: team`):
@@ -779,7 +781,7 @@ To determine if a task is frontend, backend, or fullstack, use this heuristic:
     Note the stacking in MEMORY.md. When the previous MR/PR is merged: `git -C .worktrees/feat/{next} rebase --onto main feat/{previous}`
 - **If no `[ ]` tasks remain in current phase AND at least one `[~]` exists** (all remaining were skipped): do NOT auto-advance. Delegate to `product-owner`: "All tasks in Phase [N] are blocked/skipped. The autonomous loop cannot proceed. Options: (1) ADD replacement tasks that unblock progress, (2) REPRIORITIZE to skip this phase entirely and move to next, (3) declare a BLOCKER requiring human intervention." If product-owner returns only CONFIRM with no actionable changes, STOP the autonomous loop and log: "Phase [N] fully blocked — requires human intervention. Run orchestrator manually after resolving blockers."
 - One task per invocation — after post-merge, end session. The external loop will start the next invocation.
-- **CRITICAL: ZERO commits after merge.** MEMORY.md and TODO.md are already on main (they came from the merge). Do NOT `git add`, do NOT `git commit`, do NOT create `chore:` commits. If you see tracking files as "modified" after merge, that is IMPOSSIBLE if STEP 11 was done correctly — investigate, do NOT blindly commit.
+- **CRITICAL: ZERO commits after merge.** MEMORY.md and TODO.md are already on main (they came from the merge). Do NOT `git add`, do NOT `git commit`, do NOT create `chore:` commits. If you see tracking files as "modified" after merge, that is IMPOSSIBLE if STEP 9 was done correctly — investigate, do NOT blindly commit.
 - **If no `[ ]` tasks remain in current phase AND zero `[~]` exist** (all completed) -> phase transition (handled at start of STEP 1)
 - **If no `[ ]` tasks remain in ALL phases AND zero `[~]` exist** (everything completed) -> final completion sequence:
   1. Delegate to `product-owner` agent:
@@ -815,32 +817,31 @@ For critical production bugs (outside normal TODO.md flow):
 1. Create worktree: `git worktree add .worktrees/fix/{description} -b fix/{description}` — store in MEMORY.md `Current Worktree`
 2. Delegate to architect agent for minimal fix plan (STEP 2 — cannot be skipped). Include `Working directory: {worktree-abs-path}` in prompt.
 3. Implement fix (STEP 3)
-4. Build, lint & test (STEP 5)
-5. Code review (STEP 7 — cannot be skipped). **Include in reviewer prompt**: "NOTE: This is a hotfix. Test writing was intentionally deferred — do not flag missing test coverage for this change."
-6. If reviewer finds CRITICAL or WARN issues: set `Current Step: 7 — REVIEW (hotfix rework)`, fix them and re-review (max 2 cycles for hotfixes). If still failing, commit anyway with a note in MEMORY.md — hotfix urgency takes priority.
-7. Commit & push from worktree (STEP 11) — include in the SAME commit:
+4. Code review (STEP 6 — cannot be skipped). **Include in reviewer prompt**: "NOTE: This is a hotfix. Test writing was intentionally deferred — do not flag missing test coverage for this change."
+5. If reviewer finds CRITICAL or WARN issues: set `Current Step: 7 — REWORK (hotfix)`, fix them and re-review (max 2 cycles for hotfixes). If still failing, commit anyway with a note in MEMORY.md — hotfix urgency takes priority.
+6. Commit & push from worktree (STEP 9) — include in the SAME commit:
    - Copy MEMORY.md into worktree. MEMORY.md: add note under "Notes": `Hotfix: [description] ([date])`, set `Current Task` to `(none)`, `Current Step` to `(none)`, `Current Worktree` to `(none)`
    - Do NOT update TODO.md checkboxes unless the fix corresponds to an existing task
-8. Post-merge: follow STEP 12 logic (merge to main from project root, clean up worktree + branch). No additional commits.
-9. **Patch release**: if git integration active, delegate to `devops-integrator`: "Hotfix merged. Create a patch release with changelog."
+7. Post-merge: follow STEP 10 logic (merge to main from project root, clean up worktree + branch). No additional commits.
+8. **Patch release**: if git integration active, delegate to `devops-integrator`: "Hotfix merged. Create a patch release with changelog."
 
-**Skipped steps:** STEP 4 (tests — unless the bug reveals missing test coverage), STEP 6 (visual verification).
+**Skipped steps:** STEP 4 (tests — unless the bug reveals missing test coverage), STEP 5 (visual verification).
 
-**Tracking:** During hotfix flow, update `Current Step` in MEMORY.md at each numbered step (e.g., `Current Step: hotfix — STEP 5`) for crash recovery.
+**Tracking:** During hotfix flow, update `Current Step` in MEMORY.md at each numbered step (e.g., `Current Step: hotfix — STEP 6`) for crash recovery.
 
 ## Merge Conflicts
 
 If a merge conflict occurs:
 
-**During feature branch development** (STEP 3-10, in worktree):
+**During feature branch development** (STEP 3-8, in worktree):
 1. `cd {worktree-path} && git fetch origin main && git rebase origin/main`
 2. Resolve conflicts manually — prefer keeping both changes when possible
-3. Re-run STEP 5 (build, lint & test) in the worktree after resolution
-4. If conflict changes are significant (not just trivial merge): re-run STEP 7 (code review) on affected files
+3. Re-run STEP 4 (tests) in the worktree after resolution
+4. If conflict changes are significant (not just trivial merge): re-run STEP 6 (code review) on affected files
 5. If rebase is too complex: `cd {worktree-path} && git merge origin/main` instead (creates merge commit but is safer)
 6. Log the conflict resolution in MEMORY.md Notes
 
-**During `git merge feat/branch` on main** (STEP 12, from project root):
+**During `git merge feat/branch` on main** (STEP 10, from project root):
 1. Resolve the conflict in the merge commit (do NOT rebase here — you are on main)
 2. `git add [resolved files]` (only resolved files — do NOT use `git add .`), then `git merge --continue`
 3. Verify the merged result: build, lint, test from project root
@@ -933,10 +934,10 @@ After handling the user's message, resume the development cycle from where you l
 - You are an ORCHESTRATOR — delegate to specialist agents, do not bypass them
 - Work FULLY autonomously in UNATTENDED mode; in interactive mode, handle user messages per the User Interaction section above
 - NEVER commit code that: (a) failed review, (b) failed build/lint, (c) breaks tests
-- NEVER implement without architect plan (STEP 2) or skip code review (STEP 7)
+- NEVER implement without architect plan (STEP 2) or skip code review (STEP 6)
 - Each commit = 1 logical unit
 - Conventional commits: feat/fix/refactor/chore/docs
-- **ABSOLUTE BAN: NEVER create commits that only change MEMORY.md or TODO.md.** Tracking files are committed WITH implementation code in STEP 11. After merge (STEP 12), ZERO commits — tracking files arrive on main via the merge itself. Forbidden patterns: `chore: update progress tracking`, `chore: update MEMORY.md`, `chore: update MEMORY.md tracking after ...`, `chore: log hotfix`. If tracking files show as modified after merge, something went wrong in STEP 11 — investigate and fix, do NOT create a band-aid commit.
+- **ABSOLUTE BAN: NEVER create commits that only change MEMORY.md or TODO.md.** Tracking files are committed WITH implementation code in STEP 9. After merge (STEP 10), ZERO commits — tracking files arrive on main via the merge itself. Forbidden patterns: `chore: update progress tracking`, `chore: update MEMORY.md`, `chore: update MEMORY.md tracking after ...`, `chore: log hotfix`. If tracking files show as modified after merge, something went wrong in STEP 9 — investigate and fix, do NOT create a band-aid commit.
 - All files in ENGLISH
 - TODO.md + MEMORY.md are your tracking system — keep them PRECISE and CURRENT
 - If deviating from plan, LOG the reason in MEMORY.md

package/dist/template/.claude/docker/docker-entrypoint.sh

@@ -1,6 +1,20 @@
 #!/bin/bash
 set +x
 
+# Strip \r from all env vars — Windows .env files use \r\n line endings,
+# and a trailing \r in tokens causes "invalid header field value" HTTP errors.
+# This is a blanket fix that covers all tokens (GITLAB_TOKEN, GH_TOKEN, NPM_TOKEN, etc.)
+while IFS='=' read -r name value; do
+  if [[ -n "$name" && "${!name}" == *$'\r'* ]]; then
+    export "$name"="${!name//$'\r'/}"
+  fi
+done < <(env)
+
+# Also convert project .env to LF so that `source .env` inside the container works correctly
+if [[ -f /project/.env ]]; then
+  sed -i 's/\r$//' /project/.env
+fi
+
 # npm auth — create .npmrc from env var if set
 if [[ -n "${NPM_TOKEN:-}" ]]; then
   npm_registry="${NPM_REGISTRY:-registry.npmjs.org}"

package/dist/template/.claude/templates/claude-md.md

@@ -410,7 +410,7 @@ Install these before starting autonomous development:
 
 The full development cycle is managed by the **`orchestrator` agent**. It handles:
 - Session health check (file validation, git sync, external issue intake)
-- 12-step development cycle (pick -> plan -> implement -> test -> review -> commit)
+- 10-step development cycle (pick -> plan -> implement -> test -> review -> commit)
 - Hotfix workflow, merge conflict resolution
 - Phase transitions with product re-evaluation
 - Error recovery and graceful degradation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-workspace",
-  "version": "1.1.108",
+  "version": "1.1.110",
   "author": "",
   "repository": {
     "type": "git",