nurosys-agents 2.0.0 → 2.1.0

package/.agent/frontend/skills/vuexy-component-guide/SKILL.md

@@ -367,3 +367,54 @@ For Avatars/Badges: use `skin` prop (`'filled'`, `'light'`, `'light-static'`) to
 
 For the complete component reference with every available prop and configuration option, see [reference.md](reference.md).
 For full interface examples, see [examples.md](examples.md).
+
+---
+
+## Sub-agent mode (used by `/ux-architect`)
+
+When invoked as a sub-agent by `/ux-architect`, this skill operates in **structured-output mode** and **does not respond conversationally**. Detect this mode when the parent's prompt contains "sub-agent mode" or "mode=subagent".
+
+### Input contract
+
+The parent provides a description of the proposed UI surface — one or more of:
+- A list of pages / routes
+- Dialogs, drawers, modals to be added
+- Forms with their fields and validation needs
+- Lists, tables, cards, or other display surfaces
+- States to render: empty / loading / error
+
+### Output contract
+
+Return a JSON object. Do not include narration outside the JSON.
+
+```json
+{
+  "reuse_candidates": [
+    {
+      "ui_element": "<short description of the UI piece from the parent's request>",
+      "use_component": "<one or more component names — MUI components, custom wrappers, or composition patterns>",
+      "pattern": "<short name of the form/dialog/layout pattern that fits>",
+      "ref": "<file:section anchor pointing into examples.md or reference.md, e.g. 'examples.md#user-list-dialog'>",
+      "notes": "<one or two sentences on props/composition specifics — what to set, what to avoid>"
+    }
+  ],
+  "gaps": [
+    {
+      "ui_element": "<UI piece the existing component library does NOT cover well>",
+      "why_no_reuse": "<one sentence: what's missing — no matching wrapper, requires new variant, new design token, etc.>",
+      "suggested_pattern": "<the closest existing pattern + the specific delta the team would need to add>"
+    }
+  ]
+}
+```
+
+### Sub-agent rules
+
+- **Reuse-first**: every `ui_element` from the parent's request must appear in `reuse_candidates` OR `gaps` — never both, never neither.
+- **Cite the source**: every `reuse_candidates[].ref` must point to an actual anchor in `examples.md` or `reference.md`. Do not invent references.
+- **Be honest about gaps**: if the existing library genuinely doesn't cover a need, surface it as a `gap` with a concrete suggestion rather than forcing a reuse mapping.
+- **No code in the JSON**: descriptions and component names only — `/ux-architect` is composing a plan, not writing code.
+
+### Standalone mode (unchanged)
+
+When invoked directly by the user (no "sub-agent mode" signal in the prompt), the skill behaves as before — conversational guidance with code samples, references to `examples.md` and `reference.md`, and recommendations for the user's described UI need.

package/.agent/frontend/workflows/module-runner.claude.md

@@ -0,0 +1,233 @@
+---
+name: module-runner
+description: Autonomous per-module executor for frontend features planned by `/architect` (which itself consumed `/ux-architect`'s UX plan). Sequentially runs each module's prompt through a sub-agent pipeline (build → test → lint → review → fix → security audit → fix → commit → push), keeping the main agent's context clean. Trigger with `/module-runner <feature-folder>`. Claude Code variant — uses the Task tool to spawn independent-context sub-agents.
+disable-model-invocation: false
+---
+
+# Skill: module-runner (Claude Code variant)
+
+The main agent here is the **orchestrator**. It does not implement, review, or audit anything itself. It dispatches each per-module phase to a sub-agent (Task tool, fresh context) and acts on the structured result.
+
+This keeps the main agent's context clean across 10+ module features — every heavy phase (loading project-memory, reading diffs, running review/audit logic) happens in a sub-agent that exits when done.
+
+---
+
+## Input
+
+The user invokes:
+```
+/module-runner <feature-folder>
+```
+
+Where `<feature-folder>` is `documentation/features/<feature_name>/`, containing:
+- `<feature>_MODULE_WISE_PLAN.md` — master plan
+- `<feature>_MODULE_<N>_<MODULE_NAME>.md` — one prompt per module
+
+---
+
+## Phase 0 — Validate input
+
+1. Confirm the folder exists.
+2. List `<feature>_MODULE_<N>_*.md` files. Sort by `<N>`.
+3. Confirm `<feature>_MODULE_WISE_PLAN.md` exists. Read it once to extract feature name and module count.
+4. Check git state: must be on a non-`main`/non-`master` branch. If on `main`, **STOP** and ask the user to create a feature branch first.
+5. Confirm `project-memory/` is intact (constitution, repo-map, auth-model, core-memory all present).
+
+Present a one-line summary to the user:
+> "Found N modules in <feature-folder>. Starting from Module 1. I'll commit + push after each module passes. Confirm to proceed?"
+
+Wait for confirmation.
+
+---
+
+## Per-module pipeline
+
+For each module file in order, run this pipeline. **Each numbered step is a sub-agent invocation** (Task tool, fresh context) **unless marked [Main]**.
+
+### Step 1 — Implement [Task sub-agent]
+
+Spawn a sub-agent with a self-contained prompt:
+
+> Task: Implement Module <N> — <MODULE_NAME> of feature `<feature_name>`.
+>
+> Read the full spec from: `documentation/features/<feature_name>/<feature>_MODULE_<N>_<MODULE_NAME>.md`.
+>
+> The prompt contains all curated context: UX plan references (specific sections), repo-map excerpts, architecture rules, constitution rules, design-system patterns, auth approach, prior decisions, plus the full module specification.
+>
+> If the prompt references sections of `documentation/features/<feature_name>/<feature>_UX_PLAN.md`, those are the visual/composition source of truth for any UI code you write.
+>
+> Execution rules:
+> - No placeholder code. Implement every file in the New Files / Modified Files tables.
+> - Honor constitution + design-system rules inlined in the prompt's §1.
+> - Use the documented custom wrappers and form pattern — no raw MUI when a wrapper exists.
+> - Honor `'use client'` decisions in the prompt's §1 — don't add it to a server component unintentionally.
+> - Honor the auth approach inlined in the prompt's §1 (if present).
+> - Use Serena for symbol-level edits where appropriate; raw Write for new files.
+> - When done, return a JSON summary:
+>   `{ "files_changed": [...], "summary": "<one paragraph>", "blockers": [] }`
+>
+> Do NOT run tests, do NOT commit. Implementation only.
+
+Wait for completion. If `blockers` is non-empty, **STOP** and surface to user.
+
+### Step 2 — Build + Test + Lint [Main]
+
+In the main agent:
+```bash
+npm run build
+npm test
+npm run lint  # if defined in package.json scripts; otherwise skip
+```
+
+For TypeScript-strict projects, `npm run build` already runs the type-check. If there's a dedicated typecheck script (`tsc --noEmit`), run it too.
+
+If all pass → go to Step 3.
+
+If either fails:
+- Spawn a [Task sub-agent] with the failure output:
+  > Task: The Module <N> implementation has build/test failures. Output below. Read the changed files (from the prior implementation summary) and fix the failures. Return `{ "fixed": true|false, "summary": "..." }`.
+- Re-run `npm run build` and `npm test`.
+- Allow **at most 2** fixer iterations. On the 3rd consecutive failure, **STOP** and surface to user.
+
+### Step 3 — Code review [Task sub-agent, sub-agent mode]
+
+Spawn a sub-agent invoking the `/code-reviewer` skill in sub-agent mode:
+
+> Task: Run `/code-reviewer` in sub-agent mode on the diff since the last commit. Module: <N> — <MODULE_NAME>.
+>
+> Auto-approve internal decisions per `/code-reviewer`'s sub-agent contract.
+> Return the structured findings JSON.
+
+Wait for completion. Parse the verdict:
+- `verdict = clean` → go to Step 5
+- `verdict = fix_required` → go to Step 4
+- `verdict = block` → **STOP** and surface findings to user
+
+### Step 4 — Code fixer [Task sub-agent]
+
+Spawn a sub-agent to apply the code-review findings:
+
+> Task: Apply the required-severity findings from this `/code-reviewer` output. JSON below.
+>
+> [paste the findings JSON from Step 3]
+>
+> Rules:
+> - Only fix findings marked BLOCKER, HIGH, or MED-with-`required=true`. Skip LOW and optional.
+> - Use Serena symbolic edits where the fix is symbol-shaped.
+> - Do not change scope beyond the listed findings.
+> - When done, return `{ "fixed": [<finding ids>], "skipped": [<finding ids with reason>], "summary": "..." }`.
+
+After the fixer returns, re-run `npm run build` and `npm test`. If they pass, go to Step 5. If they fail, treat as Step 2 retry (max 2 total fixer iterations before STOP).
+
+### Step 5 — Security audit [Task sub-agent, sub-agent mode]
+
+Spawn a sub-agent invoking the `/security-assessment` skill in sub-agent mode, scope = diff:
+
+> Task: Run `/security-assessment` in sub-agent mode, scope = diff (since last commit). Module: <N> — <MODULE_NAME>.
+> Return the structured findings JSON.
+
+Parse the verdict:
+- `verdict = clean` → go to Step 7
+- `verdict = fix_required` → go to Step 6
+- `verdict = block` → **STOP** and surface findings to user
+
+### Step 6 — Security fixer [Task sub-agent]
+
+Spawn a sub-agent to apply CRITICAL/HIGH security findings:
+
+> Task: Apply CRITICAL and HIGH security findings. JSON below.
+>
+> [paste findings JSON from Step 5]
+>
+> Rules:
+> - Fix every CRITICAL and HIGH. Skip MEDIUM and LOW unless explicitly tagged `must_fix`.
+> - Use Serena symbolic edits where possible.
+> - Return `{ "fixed": [...], "skipped": [...], "summary": "..." }`.
+
+After fixer returns, re-run `npm run build` and `npm test`. If they pass, go to Step 7. If they fail, **STOP** and surface to user (do not auto-retry security fixes).
+
+### Step 7 — Update project-memory [Main]
+
+In the main agent:
+
+1. Append a line to `project-memory/core-memory.md` under Completed modules:
+   > `<feature_name>: Module <N> completed (<one-line description>); next: Module <N+1>.`
+2. If the module added new modules/routes/services, update `project-memory/repo-map.md` accordingly.
+3. Update or create `MODULE.md` in the module's source directory using `.agent/templates/MODULE.md`.
+
+### Step 8 — Commit + push [Main]
+
+In the main agent:
+
+```bash
+git add .
+git commit -m "feat(MODULE_<N>): <one-line description from Step 1's implementation summary>"
+git push origin HEAD
+```
+
+If push fails (e.g. protected branch, missing upstream), surface the error and **STOP** — do not force-push, do not change branches.
+
+### Step 9 — Move to next module [Main]
+
+Print a one-line status:
+> "✅ Module <N>/<total> done. Moving to Module <N+1>."
+
+Return to Step 1 for the next module.
+
+---
+
+## After all modules
+
+Print a final summary:
+
+```
+Feature: <feature_name>
+Modules completed: <N>/<total>
+Total commits: <count>
+Branch: <current-branch>
+
+Per-module:
+- Module 1: <files changed count>, build ✅, review ✅, security ✅
+- Module 2: ...
+```
+
+Do **not** open a PR. Leave that to the user.
+
+---
+
+## Failure modes — when to STOP
+
+The runner **stops and surfaces to the user** (no automatic retry beyond what's specified per phase):
+
+- Build or test fails after 2 fixer iterations
+- `/code-reviewer` returns `verdict = block` (CRITICAL or unrecoverable findings)
+- `/security-assessment` returns `verdict = block` (CRITICAL)
+- Security fixer step fails build/tests on its first re-verification
+- `git push` fails
+- Implementation sub-agent returns non-empty `blockers`
+- Any sub-agent Task tool call errors out
+
+On STOP: clearly state which step failed, which module it was on, paste the relevant error/findings, and **do not** delete uncommitted work. The user resumes by re-running `/module-runner <feature-folder>` after fixing the blocker — the runner skips modules whose source files match the last committed state. (Detect this by checking `project-memory/core-memory.md` for "Module <N> completed" lines.)
+
+---
+
+## Sub-agent invocation contract (Claude Code Task tool)
+
+When spawning a sub-agent, the Task tool call must:
+
+- Use `subagent_type: "general-purpose"` (or a dedicated subagent type if one is configured)
+- Pass a fully self-contained prompt — the sub-agent has zero context from the main session
+- Request a JSON-shaped return value when the result will be consumed programmatically (review, security, fixer)
+- For background-friendly phases (review, security audit), use `run_in_background: true` only if Step ordering allows. The pipeline above is strictly sequential, so default to foreground.
+
+---
+
+## Do not
+
+- Implement, review, or audit in the main agent. Always delegate via Task.
+- Skip the build/test verification between phases.
+- Auto-retry beyond the limits specified.
+- Squash commits — one commit per module.
+- Push to `main` / `master` directly.
+- Open a PR — the user does that after reviewing the full branch.
+- Update `project-memory/core-memory.md` in the implementation/fixer/audit sub-agents. Only the main agent does that, in Step 7.

package/.agent/frontend/workflows/module-runner.codex.md

@@ -0,0 +1,159 @@
+---
+name: module-runner
+description: Sequential per-module executor for frontend features planned by `/architect` (which itself consumed `/ux-architect`'s UX plan). Runs each module's prompt through a foreground pipeline (build → test → lint → review → fix → security audit → fix → commit → push). Codex variant — runs all phases in a single context (no native sub-agent spawning). Trigger with `/module-runner <feature-folder>`.
+---
+
+# Skill: module-runner (Codex variant)
+
+Codex does not have native in-session sub-agent spawning (no equivalent of Claude Code's Task tool or Cursor's subagents API callable from within an agent run). This variant runs the same per-module pipeline **sequentially in a single context**.
+
+**Limitation acknowledgement:** On long features (10+ modules), this variant will accumulate context as it goes — review/audit phases load diffs and project-memory each iteration. For features with many modules, prefer Claude Code or Cursor where context isolation is native.
+
+The pipeline contract (build → test → review → fix → security → fix → commit → push) is identical; only the execution model differs.
+
+---
+
+## Input
+
+```
+/module-runner <feature-folder>
+```
+
+Where `<feature-folder>` is `documentation/features/<feature_name>/`.
+
+---
+
+## Phase 0 — Validate input
+
+1. Folder exists, module files present, sorted by `<N>`
+2. `_MODULE_WISE_PLAN.md` exists
+3. On a non-`main` branch
+4. `project-memory/` intact
+
+Confirm with the user before starting. Specifically warn:
+> "Codex variant: all phases run in this single conversation. For features with 10+ modules, context rot is possible. Continue?"
+
+---
+
+## Per-module pipeline
+
+For each module file in order:
+
+### Step 1 — Implement
+
+In this same conversation:
+
+1. Read the full module spec: `documentation/features/<feature_name>/<feature>_MODULE_<N>_<MODULE_NAME>.md`
+2. If the prompt references sections of `documentation/features/<feature_name>/<feature>_UX_PLAN.md`, those are the visual/composition source of truth for any UI code.
+3. Implement every file in the New Files / Modified Files tables.
+4. Honor constitution + design-system rules inlined in §1. Use the documented custom wrappers and form pattern — no raw MUI when a wrapper exists.
+5. Honor `'use client'` decisions inlined in §1 — don't add it to a server component unintentionally.
+6. Honor the auth approach inlined in §1.
+7. Use Serena for symbol-level edits, raw Write for new files.
+8. No placeholder code. No skipped validation/auth/error handling.
+
+Track files changed in working memory (you'll need them for commit message in Step 8).
+
+### Step 2 — Build + Test + Lint
+
+```bash
+npm run build
+npm test
+npm run lint  # if defined; otherwise skip
+```
+
+If all pass → Step 3. If any fail:
+- Inspect failures.
+- Fix.
+- Re-run.
+- Max 2 fix iterations. On 3rd failure, **STOP**.
+
+### Step 3 — Code review
+
+Invoke the `/code-reviewer` skill (foreground, same context). Capture findings.
+
+Verdict:
+- `clean` → Step 5
+- `fix_required` → Step 4
+- `block` → **STOP**
+
+### Step 4 — Apply code-review fixes
+
+Apply BLOCKER, HIGH, and required-MED findings from the review. Skip LOW.
+
+Re-run `npm run build && npm test`. If pass → Step 5. If fail → Step 2 retry logic (max 2 total).
+
+### Step 5 — Security audit
+
+Invoke the `/security-assessment` skill, scope = diff. Capture findings.
+
+Verdict:
+- `clean` → Step 7
+- `fix_required` → Step 6
+- `block` → **STOP**
+
+### Step 6 — Apply security fixes
+
+Apply CRITICAL and HIGH findings. Skip MEDIUM/LOW unless tagged `must_fix`.
+
+Re-run build/test. If pass → Step 7. If fail → **STOP** (no auto-retry).
+
+### Step 7 — Update project-memory
+
+1. Append to `project-memory/core-memory.md`:
+   > `<feature_name>: Module <N> completed (<one-line>); next: Module <N+1>.`
+2. Update `project-memory/repo-map.md` if new modules/routes added.
+3. Create/update `MODULE.md` in the module's source directory from `.agent/templates/MODULE.md`.
+
+### Step 8 — Commit + push
+
+```bash
+git add .
+git commit -m "feat(MODULE_<N>): <one-line description>"
+git push origin HEAD
+```
+
+If push fails, **STOP**.
+
+### Step 9 — Context-rot mitigation (Codex-specific)
+
+Before moving to the next module:
+
+- Discard any large intermediate artifacts from memory (review reports, security reports) — they're already saved as files if needed.
+- Re-summarize for yourself in one short paragraph: "Module <N> done. Files: [count]. Next: Module <N+1> covers [one-line]."
+
+This is the best Codex can do without true context isolation. It does not fully solve context rot but reduces it.
+
+### Step 10 — Next module
+
+Return to Step 1.
+
+---
+
+## After all modules
+
+Print final summary. Do not open a PR.
+
+---
+
+## Failure modes
+
+Same STOP conditions as the other variants:
+- Build/test fail after 2 fixer iterations
+- Review or security verdict = `block`
+- Security fixer build/test failure
+- `git push` failure
+
+Resume: re-run `/module-runner <feature-folder>`. Skip modules already marked completed in `core-memory.md`.
+
+---
+
+## Do not
+
+- Skip build/test between phases
+- Auto-retry beyond specified limits
+- Squash commits
+- Push to `main` / `master`
+- Open a PR
+- Bypass the review or security audit phases
+- Continue past 10 modules without warning the user about context rot

package/.agent/frontend/workflows/module-runner.cursor.md

@@ -0,0 +1,218 @@
+---
+name: module-runner
+description: Autonomous per-module executor for frontend features planned by `/architect` (which itself consumed `/ux-architect`'s UX plan). Sequentially runs each module's prompt through a subagent pipeline (build → test → lint → review → fix → security audit → fix → commit → push), keeping the main agent's context clean. Trigger with `/module-runner <feature-folder>`. Cursor variant — uses Cursor subagents (https://cursor.com/docs/subagents) to spawn independent-context delegates.
+disable-model-invocation: false
+---
+
+# Skill: module-runner (Cursor variant)
+
+The main agent here is the **orchestrator**. It does not implement, review, or audit anything itself. It dispatches each per-module phase to a Cursor subagent (fresh context per https://cursor.com/docs/subagents) and acts on the structured result.
+
+The pipeline is identical to the Claude Code variant; only the sub-agent invocation syntax differs.
+
+---
+
+## Required Cursor subagents
+
+This skill assumes the following Cursor subagents are configured (created during `npm exec nurosys-agent-setup`):
+
+| Subagent name | Purpose | Maps to |
+|---|---|---|
+| `/implementer` | Implements a single module per its prompt file | Step 1 |
+| `/code-reviewer` | Reviews a diff and returns findings JSON | Step 3 |
+| `/code-fixer` | Applies code-review findings to the diff | Step 4 |
+| `/security-auditor` | Audits a diff for security issues | Step 5 |
+| `/security-fixer` | Applies CRITICAL/HIGH security findings | Step 6 |
+| `/build-test-fixer` | Fixes build/test failures | Step 2 retry |
+
+If any of these subagents are missing in the Cursor workspace, **STOP** at Phase 0 and tell the user:
+> "This workspace is missing one or more required Cursor subagents: [list]. Run `npm exec nurosys-agent-setup` to install them."
+
+These subagents are thin wrappers — each is a Cursor subagent that delegates to the same SKILL.md files used by Claude Code (`/code-reviewer`, `/security-assessment`, `/auth-and-permissions`). The subagent definition lives in `.cursor/subagents/<name>.md` (created by `setup.js`).
+
+---
+
+## Input
+
+The user invokes:
+```
+/module-runner <feature-folder>
+```
+
+Where `<feature-folder>` is `documentation/features/<feature_name>/`, containing:
+- `<feature>_MODULE_WISE_PLAN.md`
+- `<feature>_MODULE_<N>_<MODULE_NAME>.md` per module
+
+---
+
+## Phase 0 — Validate input
+
+Same as Claude Code variant:
+1. Folder exists, module files present, sorted by `<N>`
+2. `_MODULE_WISE_PLAN.md` exists
+3. On a non-`main` branch
+4. `project-memory/` intact
+5. All required Cursor subagents are configured (see table above)
+
+Confirm with user before starting.
+
+---
+
+## Per-module pipeline
+
+For each module file in order, run this pipeline. Each numbered step delegates to a Cursor subagent (independent context) **unless marked [Main]**.
+
+### Step 1 — Implement
+
+Delegate to `/implementer`:
+
+> /implementer module=<N> feature=<feature_name>
+>
+> Read the full spec from: `documentation/features/<feature_name>/<feature>_MODULE_<N>_<MODULE_NAME>.md`.
+>
+> If the prompt references sections of `documentation/features/<feature_name>/<feature>_UX_PLAN.md`, those are the visual/composition source of truth for any UI code you write.
+>
+> Execution rules:
+> - No placeholder code. Implement every file in the New Files / Modified Files tables.
+> - Honor constitution + design-system rules inlined in the prompt's §1.
+> - Use the documented custom wrappers and form pattern — no raw MUI when a wrapper exists.
+> - Honor `'use client'` decisions inlined in the prompt — don't add it to a server component unintentionally.
+> - Honor the auth approach inlined in the prompt's §1.
+> - Use Serena for symbol-level edits; raw write for new files.
+> - When done, return JSON: `{ "files_changed": [...], "summary": "<one paragraph>", "blockers": [] }`.
+> - Do NOT run tests, do NOT commit.
+
+Wait for completion (foreground). If `blockers` is non-empty, **STOP** and surface to user.
+
+### Step 2 — Build + Test + Lint [Main]
+
+```bash
+npm run build
+npm test
+npm run lint  # if defined; otherwise skip
+```
+
+If all pass → Step 3.
+
+If either fails, delegate to `/build-test-fixer`:
+> /build-test-fixer module=<N>
+>
+> Failure output below. The recently changed files are: [from Step 1's `files_changed`]. Fix the failures.
+> Return `{ "fixed": true|false, "summary": "..." }`.
+
+Re-run build/test. Max 2 fixer iterations. On 3rd failure, **STOP**.
+
+### Step 3 — Code review
+
+Delegate to `/code-reviewer`:
+
+> /code-reviewer mode=subagent scope=diff module=<N>
+>
+> Return findings JSON per the `/code-reviewer` SKILL.md sub-agent contract.
+
+Parse the verdict:
+- `clean` → Step 5
+- `fix_required` → Step 4
+- `block` → **STOP**
+
+### Step 4 — Code fixer
+
+Delegate to `/code-fixer`:
+
+> /code-fixer module=<N>
+>
+> Findings JSON: [paste from Step 3]
+>
+> Apply BLOCKER, HIGH, and required-MED findings. Skip LOW and optional. Use Serena symbolic edits where possible.
+> Return `{ "fixed": [...], "skipped": [...], "summary": "..." }`.
+
+Re-run build/test. If pass → Step 5. If fail → treat as Step 2 retry (max 2).
+
+### Step 5 — Security audit
+
+Delegate to `/security-auditor`:
+
+> /security-auditor mode=subagent scope=diff module=<N>
+>
+> Return findings JSON per `/security-assessment` SKILL.md sub-agent contract.
+
+Parse the verdict:
+- `clean` → Step 7
+- `fix_required` → Step 6
+- `block` → **STOP**
+
+### Step 6 — Security fixer
+
+Delegate to `/security-fixer`:
+
+> /security-fixer module=<N>
+>
+> Findings JSON: [paste from Step 5]
+>
+> Apply CRITICAL and HIGH. Skip MEDIUM/LOW unless tagged `must_fix`.
+> Return `{ "fixed": [...], "skipped": [...], "summary": "..." }`.
+
+Re-run build/test. If pass → Step 7. If fail → **STOP** (no auto-retry on security fixes).
+
+### Step 7 — Update project-memory [Main]
+
+Same as Claude Code variant:
+1. Append "Module <N> completed" line to `project-memory/core-memory.md`
+2. Update `project-memory/repo-map.md` if new modules/routes added
+3. Create/update `MODULE.md` in the module's source directory
+
+### Step 8 — Commit + push [Main]
+
+```bash
+git add .
+git commit -m "feat(MODULE_<N>): <description>"
+git push origin HEAD
+```
+
+If push fails, **STOP**.
+
+### Step 9 — Next module [Main]
+
+Print status, return to Step 1 for next module.
+
+---
+
+## After all modules
+
+Print final summary (same format as Claude Code variant). Do not open a PR.
+
+---
+
+## Failure modes
+
+Same as Claude Code variant — `STOP` on:
+- Build/test failure after 2 fixer iterations
+- Review or security verdict = `block`
+- Security fixer build/test failure
+- `git push` failure
+- Implementation `blockers` non-empty
+- Any subagent call errors out
+
+Resume by re-running `/module-runner <feature-folder>` — runner skips modules already marked completed in `core-memory.md`.
+
+---
+
+## Cursor subagent invocation notes
+
+- Subagents have **independent context windows** (per https://cursor.com/docs/subagents) — pass everything they need explicitly. No "remember from earlier".
+- Use **foreground mode** for steps where the main agent needs the result to proceed (all steps in this pipeline). Background mode is not needed since the pipeline is strictly sequential.
+- Subagents return their final message to the parent. Request JSON output in the prompt for programmatically-consumed steps (review, security, fixers).
+- Parallelism is not used here — module-runner is sequential by design. (Cursor supports parallel subagent dispatch, but per-module steps depend on each other.)
+
+---
+
+## Do not
+
+Same prohibitions as Claude Code variant:
+- Don't implement/review/audit in the main agent
+- Don't skip build/test verification
+- Don't auto-retry beyond specified limits
+- Don't squash commits
+- Don't push to `main` / `master`
+- Don't open a PR
+- Don't update `core-memory.md` from inside subagents (Main only, Step 7)