code-ai-installer 4.0.1-b → 4.0.1-c

package/domains/development/locales/en/.agents/workflows/hotfix.md

@@ -1,74 +1,24 @@
 ---
-description: Launch the minimal 2-gate pipeline for trivial fixes (hotfix). Use for trivial fixes with blast radius ≈ 0.
+description: Launch the minimal hotfix pipeline (DEV fix+test → RG).
 ---
 
-# /hotfix — Launch Hotfix Pipeline (2 gates)
+# /hotfix — hotfix pipeline (2 gates)
 
-> 🟡 **Mode:** Hotfix — for trivial fixes with minimal risk.
-> Full pipeline: `/start-task`. Bugfix (more serious): `/bugfix`.
+> 🟡 For trivial fixes, blast radius ≈ 0. More serious — `/bugfix`, full — `/start-task`.
+> Absolute rules — in `pipeline-rules`.
 
-## When to use
+## When
+- Typos, CSS fixes (color/padding/size), single-line logic, copy-paste error.
+- 1–2 files, contracts unchanged.
 
-- Typos in text/code
-- CSS fixes (color, padding, font size)
-- Single-line logic fix
-- Copy-paste error
-- Blast radius ≈ 0 (affects 1–2 files, does not change contracts)
+## Do NOT use
+- > 2 files → `/bugfix`; changes an API contract → `/bugfix` or `/start-task`; changes UI layout/screens → `/start-task`; unsure → ask the user.
 
-## Do NOT use if
-
-- Affects > 2 files → `/bugfix`
-- Changes API contract → `/bugfix` or `/start-task`
-- Changes UI layout / adds screens → `/start-task`
-- Unsure → ask the user
-
-## Step 0: Load rules
-
-Execute `/pipeline-rules` — read the rules BEFORE starting work.
-
-## Step 1: CONDUCTOR — Classification
-
-1. Execute `view_file` on `agents/conductor.md`
-2. Confirm the task = hotfix (per Decision Tree: blast radius ≈ 0, 1–2 files)
-3. Create Mini Checklist:
-```
-[ ] HF-DEV-01   Fix + test + service restart (if applicable)
-[ ] HF-VERIFY   Self-check + GO/NO-GO
-```
-4. `notify_user` → wait for **Approved**
-
-## Step 2: DEV+TEST — Fix and self-verification
-
-1. Execute `view_file` on `agents/senior_full_stack.md`
-2. TDD:
-   - RED: test reproducing the issue (if applicable)
-   - GREEN: minimal fix
-   - REFACTOR: if necessary
-3. JSDoc on modified functions
-4. Restart affected services if applicable
-5. Self-verification:
-   - Does the fix work?
-   - Do tests pass?
-   - No regressions?
-6. Verdict: **GO ✅ / NO-GO ❌**
-7. `notify_user` → wait for **Approved**
-
----
+## Flow
+The Conductor confirms hotfix. A combined **DEV (fix+test)** gate via the MCP flow:
+- TDD where applicable (RED → GREEN → REFACTOR), JSDoc; self-check.
+- Auto-pass on a green `run_tests`; signed `mcp` (tester co-signs).
+- → **RG** — final release, signed by **the user** (`user`).
 
 ## When in doubt
-
-If during work it becomes clear that the task is more complex than a hotfix:
-> ⚠️ "Task turned out to be more complex than a hotfix. Recommend switching to /bugfix."
-
-Switching — only with user Approved.
-
----
-
-## Prompt template
-
-```
-@AGENTS.md /hotfix
-
-What to fix: [description, 1 sentence].
-File: [specific file].
-```
+If it turns out bigger than a hotfix mid-work: "Task is more complex than a hotfix → recommend `/bugfix`." Switching is the user's decision.

package/domains/development/locales/en/.agents/workflows/pipeline-rules.md

@@ -1,163 +1,80 @@
 ---
-description: Absolute development pipeline rules. MUST NOT be violated.
+description: Absolute development pipeline rules. The code-ai MCP gate machine.
 ---
 
-# 🔴 ABSOLUTE RULE: Pipeline must not be skipped
+# 🔴 ABSOLUTE RULE: pipeline must not be skipped
 
-**This rule has no exceptions. Violation = blocker.**
+**No exceptions. Violation = blocker.** The pipeline runs on the `code-ai` MCP state machine: the source of truth is `pipeline.yaml`, transitions go through MCP tools (below).
 
 ## Pipeline — 3 Modes
 
 ### 🔵 Full Pipeline (8 gates) — `/start-task`
-CONDUCTOR → PM → UX → ARCH → DEV → REV → OPS → TEST → RG
+PM → UX → ARCH → DEV → REV → OPS → TEST → RG
 
-### 🟢 Bugfix Pipeline (4 gates) — `/bugfix`
-CONDUCTOR → DEV → REV → TEST
+### 🟢 Bugfix Pipeline (3 gates) — `/bugfix`
+DEV → REV → TEST
 
 ### 🟡 Hotfix Pipeline (2 gates) — `/hotfix`
-CONDUCTOR → DEV+TEST
+DEV (fix+test) → RG
+
+> CONDUCTOR is not a gate but the orchestrator role: it classifies the task, picks the mode (Decision Tree below), and receives no new skills (uses `$board`, `$handoff`, `$gates`).
 
 ### Decision Tree (mode selection)
 ```
 User task
-  │
-  ├─ New feature / refactoring / new API / new screen?
-  │    └─ 🔵 Full Pipeline
-  │
+  ├─ New feature / refactoring / new API / screen? → 🔵 Full
   ├─ Bug in existing functionality?
-  │    ├─ Affects > 2 files or changes API contract?
-  │    │    └─ 🟢 Bugfix (4 gates)
-  │    ├─ Affects 1–2 files, blast radius ≈ 0?
-  │    │    └─ 🟡 Hotfix (2 gates)
+  │    ├─ > 2 files or changes the API contract? → 🟢 Bugfix
+  │    ├─ 1–2 files, blast radius ≈ 0?           → 🟡 Hotfix
   │    └─ Unsure → ask the user
-  │
-  └─ User explicitly specified mode (/bugfix, /hotfix)?
-       └─ Use the specified mode
+  └─ User specified the mode explicitly (/bugfix, /hotfix) → use it
 ```
 
-> Conductor **does not receive new skills** — uses existing `$board`, `$handoff`, `$gates`.
+## How a gate is passed (MCP flow)
 
-## Mandatory actions on EVERY gate (all modes)
+On every gate, in order:
+1. `current_gate` — confirm the current gate and its requirements.
+2. `classify_gate` — classify the outcome: `auto_resolve` (safe to move), `fork` (needs a user decision → `request_decision`), `exception` (failure → `report_exception`).
+3. `load_role` on the gate's owner role → pass its protocol step by step; load required skills via `get_skill`.
+4. Produce the deliverable + `submit_artifact`.
+5. `sign_off` — sign the gate per its policy (see the sign-off model).
+6. `advance_gate` — move to the next gate.
 
-1. `view_file` on `agents/<role>.md` — read the agent protocol
-2. Follow **its** instructions, use **its** skills
-3. Produce deliverable + Handoff Envelope
-4. Present the result to the user via `notify_user`
-5. **Wait for explicit "Approved" from the user** before moving to the next gate
+## 🟢 Sign-off model — silent-by-default (reduced intervention)
 
----
+The machine flows silently; the user is pulled in only for judgment decisions.
 
-## 🛑 STOP RULES (before any code action)
-
-### Rule 1: Agent protocol — step by step, no collapsing
-Each paragraph (§) in the agent file = **a separate step**.
-- Agent MUST pass ALL paragraphs in the order specified in the file
-- Collapsing multiple §§ into a single response is forbidden
-- If agent skips a §, it MUST state the reason: "§X skipped: [reason]"
-
-### Rule 2: Code is applied ONLY after full protocol pass
-- ❌ Must not: write code first → then write the report
-- ✅ Must: pass all §§ of the protocol → present plan → Approved → apply code
-
-### Rule 3: Full response format — no shortcuts
-- Use **"Agent Response Format (strict)"** from the agent file
-- Every section of the format is MANDATORY — skipping = violation
-- If a section is not applicable, explicitly write: "N/A — [reason]"
-
-### Rule 4: Fix Cycle — full pass through agents
-On FAIL at any gate:
-1. Current agent (e.g. Tester) produces FAIL Report + HANDOFF Envelope → DEV
-2. DEV reads `agents/senior_full_stack.md` and passes FULL protocol (§0–§7)
-3. DEV HANDOFF → REV → OPS → TEST (each gate with view_file + protocol + Approved)
-4. No "quick fixes" without passing through agents
-
-### Rule 5: Self-check before notify_user
-Before each `notify_user` the agent MUST internally verify:
-- [ ] Did I read the agent file (`view_file` on `agents/<role>.md`)?
-- [ ] Did I pass ALL paragraphs of the protocol?
-- [ ] Am I using the FULL response format?
-- [ ] Is there a HANDOFF Envelope with ALL mandatory fields?
-- [ ] Did I NOT apply code before receiving Approved?
+| Gate | Signed by | How |
+|------|-----------|-----|
+| PM / UX / ARCH | **User** (`user`) | judgment decision: what & why we build |
+| DEV / REV | Claude (`mcp`) | by agent judgment (development / review) |
+| OPS / TEST | Claude (`mcp`) | after a green auto-check: `build` (OPS), `run_tests` (TEST) |
+| RG | **User** (`user`) | final release |
 
----
+- The user sees only: judgment gates (PM/UX/ARCH/RG) and an explicit escalation via `request_decision` (a `fork` classification).
+- Routine passes are not confirmed by the user.
 
-## Prohibited
+## 🔁 Red, Fix Cycle and Circuit Breaker
 
-- ❌ "Fast-tracking" gates (skipping multiple gates at once)
-- ❌ Interpreting "Confirmed" as permission to skip gates
-- ❌ Starting the pipeline without explicit user permission
-- ❌ Moving to the next gate without "Approved" from the user
-- ❌ Writing code (DEV gate) before passing prior gates
-- ❌ Applying code before completing the full agent protocol
-- ❌ Shortening the response format (every section is mandatory)
-- ❌ Ignoring protocol paragraphs, considering the task "trivial"
-- ❌ Lying about reading the protocol (if no `view_file` — it was not read)
+- A **red auto-check** (OPS/TEST) or a review/test FAIL → rollback to **DEV** (Fix Cycle), not to the user. DEV fixes → forward along the band again.
+- **Circuit Breaker:** 2 rollbacks to DEV across the DEV/OPS/REV/TEST band (`dev_rollback_threshold`) → the machine refuses to advance and requires an **architect deep audit in a FRESH session** (clean context: the same Claude that hit the wall reproduces the blind spot). Audit skills: `system-design-checklist`, `current-state-analysis`, `design-patterns-reference`.
+- **Counter reset:** on passing RG or on a new ARCH ADR (`record_decision` at the ARCH gate).
 
----
+## ✅ What is mandatory (kept)
 
-## 🔒 MECHANICAL BLOCKS
+- Gates must not be skipped, merged, or reordered without an explicit user decision.
+- Every gate has a concrete deliverable; without it the gate is not closed (`$gates` check).
+- The role protocol is passed step by step, no collapsing; a skipped step needs an explicit reason.
+- TDD at DEV: RED → GREEN → REFACTOR.
+- Decisions affecting architecture/contracts are recorded as an ADR via `record_decision`.
 
-> These rules were introduced after an incident where the agent ignored the pipeline,
-> auto-approved the ARCH gate, ignored an open user question,
-> wrote code without TDD, and delivered a broken preview.
+## 📊 Touchpoint budget (health signal)
 
-### Block 1: ShouldAutoProceed = false ALWAYS
-```
-notify_user → ShouldAutoProceed: false
-```
-No exceptions. On EVERY notify_user. Even on "trivial" gates.
-Even if the agent is "confident". The user ALWAYS decides.
-
-### Block 2: Pre-flight check before ANY write_to_file / replace_file_content
-Before every code-writing tool call the agent MUST:
-1. Quote the LAST user message containing the word "Approved"
-2. If there is no quote — CODE MUST NOT BE WRITTEN
-3. System-generated messages are NOT considered "Approved"
-4. Auto-proceeded artifacts are NOT considered "Approved"
-
-### Block 3: Answering a question — quoting is mandatory
-If the agent asked the user a question:
-1. The agent's next response MUST start with: `> Your answer: [exact quote]`
-2. If there is no quote — no answer was given — STOP, repeat the question
-3. Guessing the answer for the user is forbidden
-4. Accepting a system-generated message as an answer is forbidden
-
-### Block 4: Strict TDD (DEV gate)
-1. RED: write FAILING tests FIRST
-2. GREEN: minimal code to make tests pass
-3. REFACTOR: improve code without changing behavior
-4. Writing code before tests = violation = blocker
-
-### Block 5: Skills — mandatory reading via view_file
-Each agent (`agents/<role>.md`) references skills in `.agents/skills/`.
-1. Agent MUST execute `view_file` on `SKILL.md` of EVERY skill referenced in the agent protocol
-2. If there was no `view_file` — the skill is NOT considered applied
-3. Patterns, anti-patterns, code examples, best practices from skills — mandatory for application
-4. In the deliverable the agent MUST state: `Skills applied: [list]` with `view_file` confirmation
-5. Formal checkmarks without actual reading = violation = blocker
+Expected number of user touchpoints per task type (from `pipeline.yaml`): hotfix 1; bugfix 1–2; backend feature 1–3; UI feature with an ARCH fork 3–5; complex (3+ Fix Cycles) 3–6. Going over is a reason to revisit scope, not to "push through".
 
----
+## ❌ Prohibited
 
-## Mandatory artifacts
-
-### task.md (Antigravity brain — automatic)
-- **Created by:** Conductor at Gate 0
-- **Updated by:** EVERY agent after completing their gate
-- **Contains:** Master Checklist + Handoff Envelopes Status + Fix Cycle tracking
-- **Rule:** If task.md is not updated after a gate — the gate is not considered complete
-
-### implementation_plan.md
-- **Created by:** Architect at Gate 3 (ARCH) — or Conductor, if the task does not require ARCH
-- **Saved to:** `docs/reports/architect/plan-<task-name>.md` (in the project)
-- **Contains:** Proposed Changes + files + Verification Plan
-- **Rule:** DEV must read the plan before starting implementation. Reviewer references it during code review.
-
-### walkthrough.md (Antigravity brain — automatic)
-- **Created by:** Tester at Gate 7 (TEST) — or Release Gate
-- **Contains:** what was done, what was verified, validation results
-- **Rule:** update on each Fix Cycle and before Release Gate
-
-### docs/architecture.md + docs/ADR-log.md (in the project)
-- **Updated by:** Architect on any architectural decision
-- **Referenced by:** Reviewer and Architect on each gate
-- **Rule:** New ADRs are added to ADR-log.md. Architecture.md is updated when the stack, patterns, or constraints change
+- Skipping gates or "fast-tracking" several at once.
+- Advancing a gate without `sign_off` per its policy.
+- Writing code (DEV) before passing the prior gates and before a plan.
+- Silently bypassing the rollback/breaker: 2 rollbacks → an ARCH audit, not "one more try" in the same context.

package/domains/development/locales/en/.agents/workflows/start-task.md

@@ -1,130 +1,26 @@
 ---
-description: Template for launching a task through the 8-agent pipeline. Use at the start of EVERY session.
+description: Launch a task through the full pipeline (8 gates). The code-ai MCP gate machine.
 ---
 
-# /start-task — Launch a task through the pipeline
+# /start-task — launch the full pipeline
 
-## Step 0: Select pipeline mode
+Full mode: PM → UX → ARCH → DEV → REV → OPS → TEST → RG.
+Bugfix → `/bugfix`, trivial fix (blast radius ≈ 0) → `/hotfix`.
+Absolute rules — in `pipeline-rules` (the code-ai MCP gate machine).
 
-Determine the task type and choose the workflow:
-- 🔵 **New feature / refactoring** → continue with `/start-task` (this file)
-- 🟢 **Bugfix** (> 2 files, non-trivial) → switch to `/bugfix`
-- 🟡 **Hotfix** (1–2 files, blast radius ≈ 0) → switch to `/hotfix`
+## 1. Start
+- The Conductor classifies the task and confirms the mode (Decision Tree in `pipeline-rules`).
+- The Conductor initializes the board (`$board`) and the initial handoff (`$handoff`). It receives no new skills.
 
-> If you selected `/bugfix` or `/hotfix` — stop reading this file and follow the chosen workflow.
+## 2. Each gate — MCP flow
+`current_gate` → `classify_gate` → `load_role` (the gate's role) + `get_skill` → deliverable + `submit_artifact` → `sign_off` → `advance_gate`.
 
-## Step 1: Load pipeline rules
+## 3. Sign-off — silent-by-default
+- **The user signs only PM / UX / ARCH / RG** (judgment decisions) and `fork` escalations via `request_decision`.
+- DEV / REV — Claude (`mcp`) by judgment; OPS / TEST — auto-pass on a green `build` / `run_tests`.
 
-Execute `/pipeline-rules` — read and acknowledge ALL rules BEFORE starting work.
+## 4. Clarifying questions
+Agents with a Clarification section (PM 5+, ARCH 5–10, Tester 5+) ask questions BEFORE working and wait for the answer. Exception — the user wrote "no questions".
 
-## Step 2: Initialize agents
-Execute `view_file` on `AGENTS.md` — confirm the list of agents and skills.
-
-## Step 3: Launch the Conductor
-Execute `view_file` on `agents/conductor.md` — read the protocol and create the Master Checklist in `task.md`.
-
-## Step 4: Pass each gate STRICTLY by protocol
-
-On EVERY gate, mandatory steps:
-1. `view_file` on `agents/<role>.md` — read the agent protocol
-2. Pass EACH section of the protocol in order (no "collapsing")
-3. Use the **full** "Agent Response Format (strict)" from the agent file
-4. If a section is not applicable — explicitly write: "N/A — [reason]"
-5. Produce deliverable + Handoff Envelope with ALL mandatory fields
-6. Present the result via `notify_user`
-7. **Wait for explicit "Approved"** before moving to the next gate
-
-## Step 5: Code — ONLY after DEV gate + Approved
-
-- First, the DEV agent passes ALL sections of the protocol (§0–§7)
-- Then proposes the change plan
-- User approves
-- ONLY THEN the agent applies code
-
-## Step 6: Fix Cycle (on FAIL)
-
-If the tester or reviewer finds a bug:
-1. Current agent produces FAIL Report + HANDOFF Envelope → DEV
-2. User approves FAIL HANDOFF
-3. DEV reads `agents/senior_full_stack.md` and passes the FULL protocol
-4. DEV HANDOFF → REV → OPS → TEST (each gate with full protocol)
-5. No "quick fixes" without passing through agents
-
----
-
-## First prompt template (copy and fill)
-
-```
-@AGENTS.md /pipeline-rules
-
-Task: [what to do, 1-2 sentences].
-Files: [specific files, if known].
-
-Rules:
-1. Start with the Conductor (agents/conductor.md)
-2. Each gate: view_file → ALL protocol sections → full format → Approved
-3. Do not apply code until DEV gate + my Approved
-4. Fix Cycle = full pass through agents
-```
-
----
-
-## Session recommendations
-
-- **One session = 3-4 gates maximum** (context is preserved)
-- **Approved is given on EACH gate**, not per session
-- **Session 1:** Conductor → Approved → PM → Approved → UX → Approved
-- **Session 2:** ARCH → Approved → DEV → Approved → REV → Approved
-- **Session 3:** OPS → Approved → TEST → Approved → RG → Approved
-- Each new session — start with `/start-task`
-
-## Mandatory questions from agents
-
-Each agent that has a Clarification/Questions section in their protocol MUST:
-1. Ask questions to the user BEFORE performing work
-2. Minimum questions (from agent protocol): PM — 5+, ARCH — 5-10, DEV — as needed, Tester — 5+
-3. If the task seems "obvious" — still ask at minimum 2-3 clarifying questions
-4. Wait for user answers BEFORE continuing
-5. The only exception: the user explicitly wrote "no questions"
-
-## When "cutting corners" — one phrase
-
-If the model shortcuts, say:
-> "Stop. Section [X] of protocol agents/<role>.md. Re-read and execute."
-
----
-
-## Feedback protocol (mandatory)
-
-The model MUST provide feedback to the user at every stage:
-
-### 1. Warning when tempted to shortcut
-If the task looks "trivial", the model MUST write:
-```
-⚠️ Task looks trivial. My instinct is to do it quickly.
-But following the protocol, I'm going through the full cycle. Sections: [list].
-```
-
-### 2. User prompt assessment
-At the start of each task the model assesses the prompt:
-```
-📊 Prompt assessment:
-- Clarity: [high/medium/low]
-- What helped: [what was useful]
-- What's missing: [what to add for effectiveness]
-```
-
-### 3. Tips in Handoff Envelope
-In each Handoff add a section:
-```
-💡 Feedback: [tip for the user, if any]
-```
-
-### 4. Retrospective at session end
-Before finishing work:
-```
-🔄 Retrospective:
-- Gates passed: X
-- Protocol violations: X
-- What to improve in the next session: [recommendation]
-```
+## 5. Fix Cycle / breaker
+Red (review/test FAIL, red auto-check) → rollback to DEV. 2 rollbacks across the DEV/OPS/REV/TEST band → an architect deep audit in a fresh session (see `pipeline-rules`).

package/domains/development/locales/en/AGENTS.md

@@ -184,3 +184,18 @@ function add(a, b) {
 ## Mandatory TDD rule
 - Apply the TDD cycle to all development tasks: RED -> GREEN -> REFACTOR.
 - This requirement is mandatory for DEV and REV stages (same as JSDoc).
+
+---
+
+## Mandatory Docker container restart rule
+- For every code change, DevOps must automatically restart the affected Docker service before handing off to REVIEW/TEST. This is an **implicit** rule — it runs as part of the task, without asking for separate permission.
+- **Service resolution (do not hardcode names from a specific product):**
+  - Inspect the active Compose file (`docker-compose.yml`, `docker-compose.yaml`, `compose.yml`, or `compose.yaml`).
+  - Identify the owner of the changed path via `build.context`, bind-mounted `volumes`, and the repo's service-naming conventions.
+  - Restart the **Compose service** name, not the container name (container names are project-specific).
+- **Commands:**
+  - Runtime-code-only changes: `docker compose restart <service>`.
+  - `Dockerfile`/dependency/build/compose-config changes: `docker compose up -d --build <service>`.
+  - Multiple affected services in one command: `docker compose restart <service_one> <service_two>`.
+- Infrastructure-only changes (`infra/`, compose files, reverse-proxy config) and config/env-only changes do **not** trigger an app-service restart. For proxy/gateway/shared-routing changes, also restart `gateway`.
+- DevOps must attach evidence to the report: which services were restarted, which commands ran, and the health/smoke result after restart.