gitea-admin/CASAN
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(structure): promote app to repo root + remove redundant workspace cruft

Browse Source 
Standard production layout: the OKR app (was nested under AINative_OKR_CASAN5/) is now
the repository root. No more wrapper directory.

- Promote AINative_OKR_CASAN5/* -> repo root (backend/ frontend/ packages/ apps/
  .specify/ docs/ infra/ nginx/ scripts/ + configs). Merge tool dirs: .gitea (kept the
  active deploy ci.yml, added harness-ci.yml + runbooks), .claude (agents/commands +
  launch.json), .github moved up.
- Remove redundant: 00_SUBMISSION_PACKAGE, scattered root notes (FPT_CASAN_Full.md,
  tu-tuong-casan.md, casan-tu-sinh..., casan_harness_assessment.md, source-review...,
  README_CASAN5_REFINED.md), casan-next-plans/ and optimize-docs/ (competition/planning
  artifacts — roadmap + design history preserved in git log / commit messages).
- Update all references to the old layout:
  - .gitea/workflows/{ci,harness-ci}.yml, .github/workflows/{ci,deploy}.yml:
    working-directory .; drop AINative_OKR_CASAN5/ prefix; .specify/{tests,scripts}
    -> packages/casan-harness/... (.specify/logs state kept)
  - .claude/launch.json, .gitea/*-runbook.md: path prefixes
  - CLAUDE.md, README.md: docs/input -> apps/okr/domain/input
  - policy-bundle.yaml: 8 policy paths -> packages/casan-harness/...; manifest re-signed
- secrets-scan.sh: fixture excludes -> new package/domain paths.

Full gate from the new root: PASS=64 FAIL=0 SKIP=3.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
thanhnv
2026-07-08 13:26:36 +09:00
co-authored by Claude Opus 4.8
parent 7101af9fd4
commit 36a4812ef3
925 changed files with 410 additions and 18001 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/agents/steps/step-13-launch.md
+94
View File
@@ -0,0 +1,94 @@
# Step 13: Launch
> Boss MUST read this file before executing Step 13.
> Protocols referenced: `protocols/report-gate-protocol.md`
---
## STEP 13 — Build, Connect DB & Launch Screen
> ✅ Step 12 verdict = ALL TESTS PASS → launch with confidence.
> ⚠ Step 12 verdict = FAIL (after 3 cycles) → still launch, but notify user of known defects.
> ⚠ All code errors MUST have been resolved in Steps 10–12. STEP 13 does NOT fix code.
| Key | Value |
|-----|-------|
| Agent | Boss (self — direct execution) |
| Report | `reports/13-launch-report.md` |
| Gate | REPORT HARD GATE (+ "Launch Status" section required) |
| Max retries | 5 |
### ⛔ PRE-LAUNCH: Environment Detection (MANDATORY — run FIRST)
Before ANY build/start command, Boss MUST detect the runtime environment:
```
1. Check Docker availability:
- Run: `docker --version` (or `docker info`)
- If SUCCEEDS → Docker mode (use docker-compose)
- If FAILS → Local mode (fallback to SQLite + local Node)
2. Check database availability (Local mode only):
- If MySQL/PostgreSQL configured in docker-compose.yml but Docker unavailable:
→ Switch Prisma schema to SQLite provider
→ Create .env with DATABASE_URL="file:./dev.db"
→ Remove enum definitions (SQLite does not support enums)
→ Create local TypeScript type definitions to replace Prisma enums
→ Run: npx prisma migrate dev --name init && npx prisma db seed
3. Check port availability:
- Run: `netstat -ano | findstr :<PORT>` (Windows) or `lsof -i :<PORT>` (Unix)
- If port in use → kill existing process BEFORE starting new one
- Log [ISSUE] entry with killed PID
4. Verify .env file exists:
- backend/.env MUST exist with at minimum: DATABASE_URL, JWT_SECRET
- If missing → CREATE it with sensible defaults for local dev
- JWT_SECRET MUST be read from env, NEVER hardcoded in source
```
### Execution — Boss builds & launches directly (no delegation)
Boss MUST directly:
1. **Build Backend:**
- `cd backend && npm install && npm run build`
- If build fails, log `[ISSUE]` and retry (do NOT fix code — code must be clean from Steps 10–12)
2. **Connect DB (if the chosen stack uses a database):**
- **Docker mode:** Start Docker infrastructure: `docker-compose up -d` (or `docker compose -f docker/docker-compose.dev.yml up -d`)
- **Local mode (Docker unavailable):**
- Verify `backend/.env` has `DATABASE_URL` pointing to SQLite file
- Run `cd backend && npx prisma migrate dev --name init` if no migrations exist
- Run `cd backend && npx prisma db seed` to populate data
- Verify the application can connect to the configured database
3. **Build Frontend:**
- `cd frontend && npm install && npm run build`
- (Output is bundled to `backend/src/static/`)
4. **Start Backend (background):**
- **FIRST:** Kill any existing process on the backend port (default 3000):
- Windows: `Get-Process -Id (Get-NetTCPConnection -LocalPort 3000).OwningProcess -ErrorAction SilentlyContinue | Stop-Process -Force`
- Unix: `lsof -ti:3000 | xargs kill -9`
- `cd backend && node dist/main.js &`
- Wait for startup confirmation in logs
5. **Start Frontend dev server (background, for screen verification only):**
- **FIRST:** Kill any existing process on port 5173 (same pattern as above)
- `cd frontend && npm run dev`
- Confirm dev server is listening on `http://localhost:5173`
6. **Verify screens:**
- Read `docs/output/specs/<feature-id>/spec.md` → find first screen route (`SCR-MOD[XX]-01` URL path)
- Confirm screens are accessible and data is visible from DB (not mock)
7. **Open browser:**
- **Call `open_browser_page`** with URL: `http://localhost:5173/<first-screen-route>`
- This is the **final mandatory deliverable** of the pipeline
- The user MUST see the running UI without manual action
8. **Write `[END]`** entry in boss log with the exact URL
### Auto-Retry Gate
- All screens accessible + data visible → write `[END]` pipeline complete
- Startup errors → Auto-Retry Loop (max 5 retries):
1. Write `[ISSUE]` in boss log
2. Retry startup sequence
3. If retry > 5: `[ESCALATION]`, mark PARTIAL COMPLETE
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
.claude/agents/steps/steps-01-04-design.md
+226
View File
@@ -0,0 +1,226 @@
# Steps 1–4: Design Phase
> Boss MUST read this file before executing Steps 1–4.
> Protocols referenced: `protocols/auto-resolve-protocol.md`, `protocols/report-gate-protocol.md`
---
## STEP 0 — Pipeline Initialization (MANDATORY BEFORE ALL STEPS)
**Agent**: Boss (self)
### 0a — Validate $ARGUMENTS structure
Parse the `$ARGUMENTS` block received from the skill:
```
If $ARGUMENTS contains key "feature-id:" → pipeline-mode: UPDATE (resume existing)
If $ARGUMENTS is raw text description → pipeline-mode: CREATE (new feature)
```
For **UPDATE** mode: extract `feature-id`, `module-id`, `pipeline-context` path from args.
For **CREATE** mode: derive a new `feature-id` (scan `docs/output/output_logs/` for next available ID).
### 0b — Existing Spec Detection
Scan `docs/output/specs/` directory for existing feature/module match before creating anything.
```
Run: Get-ChildItem docs/output/specs/ -Directory | Select-Object -ExpandProperty Name
```
1. Extract module keyword from `$ARGUMENTS` (e.g., "MOD-01", "Objective")
2. Look for matching folder in `docs/output/specs/`
3. If match found:
- Set `<feature-id>` = existing folder name
- Set pipeline mode = **UPDATE** (do NOT create new branch/folder)
4. If no match:
- Set pipeline mode = **CREATE**
**Update Mode Rules:**
- **PROHIBITED:** Creating a new numbered folder when one already exists for this module.
- SRS/BD re-generation (Steps 1 & 2): Run normally — overwrite existing files.
- Spec update (Step 3): Invoke `speckit.specify` with: *"Update existing spec at `docs/output/specs/<feature-id>/spec.md` in-place. DO NOT create new branch or folder."*
### 0c — Create pipeline-context.yaml (HARD GATE)
Create the pipeline context file at:
```
docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
Write with ALL immutable fields populated:
```yaml
feature-id: <feature-id>
module-id: <mod-id>
module-keyword: <keyword>
module-short-name: <short-name>
mode: autonomous
language: Vietnamese
tech-stack: # read from docs/technical_architecture.md
backend: "..."
frontend: "..."
db: "..."
steps:
step-0:
status: COMPLETE
pipeline-mode: CREATE | UPDATE
step-1-srs:
status: PENDING
step-2-bd:
status: PENDING
step-3-spec:
status: PENDING
step-4-clarify:
status: PENDING
step-5-review-spec:
status: PENDING
step-6-plan:
status: PENDING
step-7-review-plan:
status: PENDING
step-8-dd:
status: PENDING
step-8b-testcases:
status: PENDING
step-9-tasks:
status: PENDING
step-10-implement:
status: PENDING
step-11-review-code:
status: PENDING
step-12-testkit:
status: PENDING
step-13-launch:
status: PENDING
```
**HARD GATE:** Boss MUST NOT proceed to Step 1 until this file is verified present on disk.
Use Read tool to confirm the file exists and has the correct structure.
If creation fails: log `[ISSUE]` and retry before continuing.
### 0d — Create boss log
Create `docs/output/output_logs/<feature-id>/00-boss.log.md` with the opening `[START]` entry per `protocols/log-formats.md`.
> Write `[STEP 0]` entry in boss log per `protocols/log-formats.md`.
---
## STEP 1 — SRS Generation
| Key | Value |
|-----|-------|
| Agent | `okr.srs` |
| Model | `gpt-5.4` |
| Input | Module keyword from `$ARGUMENTS` |
| Output | `docs/output/ipa-docs/srs/srs-<MOD-ID>-<short-name>.md` |
| Report | `reports/01-srs-report.md` |
| Gate | REPORT HARD GATE |
| On fail | Log error, continue with empty SRS stub |
**Delegation `$ARGUMENTS`:**
```yaml
feature-id: <feature-id>
module-id: <mod-id>
module-keyword: <keyword>
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**After completion:** Parse `<!-- STEP-RESULT -->` block, update `pipeline-context.yaml`.
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 2 — BD Generation (External Design)
| Key | Value |
|-----|-------|
| Agent | `okr.bd` |
| Model | `gpt-5.4` |
| Input | `docs/output/ipa-docs/srs/srs-<MOD-ID>-<short-name>.md`, `docs/output/srs-systems/srs-overview-system.md`, `docs/technical_architecture.md` |
| Output | `docs/output/ipa-docs/bd/bd-<MOD-ID>-<short-name>.md` |
| Report | `reports/02-bd-report.md` |
| Gate | REPORT HARD GATE + Auto-Resolve |
| On fail | Log error, continue with empty BD stub |
**Delegation `$ARGUMENTS`:**
```yaml
feature-id: <feature-id>
module-id: <mod-id>
module-keyword: <keyword>
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**After completion:** Auto-resolve any `[NEEDS CLARIFICATION]` markers in BD per `protocols/auto-resolve-protocol.md`.
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 3 — Spec Creation
| Key | Value |
|-----|-------|
| Agent | `speckit.specify` |
| Model | `gpt-5.4` |
| Input | Feature description, `docs/output/ipa-docs/srs/srs-<MOD-ID>-<short-name>.md`, `docs/output/ipa-docs/bd/bd-<MOD-ID>-<short-name>.md` |
| Output | `docs/output/specs/<feature-id>/spec.md` |
| Report | `reports/03-specify-report.md` |
| Gate | REPORT HARD GATE + Post-Check Auto-Resolve |
**Delegation `$ARGUMENTS`:**
```yaml
feature-id: <feature-id>
module-id: <mod-id>
srs-path: <from pipeline-context>
bd-path: <from pipeline-context>
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**POST-CHECK (boss does after agent returns):**
1. Read generated spec file
2. Collect all `[NEEDS CLARIFICATION]` markers
3. For each: apply Auto-Resolve Protocol — replace marker in spec
4. Write `[AUTO-RESOLVE]` entry in boss log
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 4 — Consolidated Spec Clarification (Autonomous Mode)
| Key | Value |
|-----|-------|
| Agent | `speckit.clarify` |
| Model | `gpt-5.4` |
| Input | `docs/output/specs/<feature-id>/spec.md` |
| Output | Updated spec + `reports/04-clarify-qa.md` |
| Report | `reports/04-clarify-report.md` |
| Gate | REPORT HARD GATE (+ QA Summary section required) |
**Autonomous behavior (NO PAUSE):**
1. `speckit.clarify` identifies ambiguities → produces QA list
2. Boss applies Auto-Resolve Protocol to every question
3. Boss encodes all answers back into spec
4. Boss writes QA list with answers to `reports/04-clarify-qa.md`
5. Confirms no `[NEEDS CLARIFICATION]` markers remain
**Output format for `04-clarify-qa.md`:**
```markdown
# Clarification Q&A — Auto-Resolved
| # | ID | Question | Auto-Answer | Rationale | Confidence |
|---|----|----------|-------------|-----------|------------|
| 1 | TBC-01 | ... | ... | ... | High |
## Summary
- Total questions: N
- Auto-resolved: N (High: X, Med: Y, Low: Z)
- Pending user confirmation: 0 (pipeline continues)
```
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
.claude/agents/steps/steps-05-07-review.md
+70
View File
@@ -0,0 +1,70 @@
# Steps 5–7: Review Phase
> Boss MUST read this file before executing Steps 5–7.
> Protocols referenced: `protocols/gate-retry-protocol.md`, `protocols/report-gate-protocol.md`
---
## STEP 5 — Thorough Spec Review (Auto-Retry)
| Key | Value |
|-----|-------|
| Agent | `okr.reviewspec` |
| Model | `claude-sonnet-4-6` |
| Input | `docs/output/specs/<feature-id>/spec.md`, `docs/output/ipa-docs/srs/srs-<MOD-ID>-<short-name>.md`, `constitution.md` |
| Report | `reports/05-review-spec-report.md` |
| Gate | REVIEW GATE (Auto-Retry) + REPORT HARD GATE |
| Fix agent | `speckit.specify` |
| Max retries | 5 |
**Gate logic:**
- ✅/⚠️ → proceed to Step 6
- ❌ REJECTED → invoke `speckit.specify` to fix CRITICAL issues → re-invoke `okr.reviewspec` → repeat until pass or retry > 5
- Escalation after 5 retries → continue to Step 6
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 6 — Implementation Planning
| Key | Value |
|-----|-------|
| Agent | `speckit.plan` |
| Model | `gpt-5-3-codex` |
| Input | `docs/output/specs/<feature-id>/spec.md`, `constitution.md`, `docs/technical_architecture.md` |
| Output | `docs/output/specs/<feature-id>/plan.md`, `docs/output/specs/<feature-id>/data-model.md`, `docs/output/specs/<feature-id>/contracts/` |
| Report | `reports/06-plan-report.md` |
| Gate | REPORT HARD GATE + Auto-Resolve |
**Delegation `$ARGUMENTS`:**
```yaml
feature-id: <feature-id>
module-id: <mod-id>
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**After completion:** Auto-resolve any `[NEEDS CLARIFICATION]` markers in plan artifacts.
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 7 — Plan Conformance Review (Auto-Retry)
| Key | Value |
|-----|-------|
| Agent | `okr.reviewplan` |
| Model | `claude-sonnet-4-6` |
| Input | `docs/output/specs/<feature-id>/plan.md`, `docs/output/specs/<feature-id>/spec.md`, `docs/output/specs/<feature-id>/data-model.md`, `docs/technical_architecture.md` |
| Report | `reports/07-review-plan-report.md` |
| Gate | REVIEW GATE (Auto-Retry) + REPORT HARD GATE |
| Fix agent | `speckit.plan` |
| Max retries | 5 |
**Gate logic:**
- ✅/⚠️ → proceed to Step 8
- ❌ REJECTED → invoke `speckit.plan` to fix → re-invoke `okr.reviewplan` → repeat
- Escalation after 5 retries → continue to Step 8
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
.claude/agents/steps/steps-08-09-detail.md
+101
View File
@@ -0,0 +1,101 @@
# Steps 8–9: Detail Design Phase
> Boss MUST read this file before executing Steps 8–9.
> Protocols referenced: `protocols/auto-resolve-protocol.md`, `protocols/report-gate-protocol.md`
---
## [PARALLEL GROUP A] — Steps 8 + 9 (Dispatch Simultaneously After Step 7)
> Boss MUST dispatch STEP 8 and STEP 9 as a **single multi-agent call** immediately after Step 7 gate PASSES.
> Do NOT wait for Step 8 to finish before starting Step 9, or vice versa.
> See `protocols/parallel-execution-protocol.md` (inline in boss prompt) for rules.
---
## STEP 8 — DD Generation (Internal Design)
| Key | Value |
|-----|-------|
| Agent | `okr.dd` |
| Model | `gpt-5-3-codex` |
| Input | BD, SRS, spec, plan, technical architecture |
| Output | `docs/output/ipa-docs/dd/dd-<MOD-ID>-<short-name>.md` |
| Report | `reports/08-dd-report.md` |
| Gate | REPORT HARD GATE + Auto-Resolve |
| On fail | Log error, continue with empty DD stub |
| Parallel group | GROUP A — runs concurrently with STEP 9 |
**Delegation `$ARGUMENTS`:**
```yaml
feature-id: <feature-id>
module-id: <mod-id>
module-keyword: <keyword>
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**After completion:** Auto-resolve any `[NEEDS CLARIFICATION]` markers in DD.
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 9 — Task Generation
| Key | Value |
|-----|-------|
| Agent | `speckit.tasks` |
| Model | `gpt-5.4` |
| Input | `docs/output/specs/<feature-id>/plan.md`, `docs/output/specs/<feature-id>/spec.md`, `docs/output/specs/<feature-id>/data-model.md` |
| Output | `docs/output/specs/<feature-id>/tasks.md` |
| Report | `reports/09-tasks-report.md` |
| Gate | REPORT HARD GATE + Auto-Resolve |
| Parallel group | GROUP A — runs concurrently with STEP 8 |
**Delegation `$ARGUMENTS`:**
```yaml
feature-id: <feature-id>
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**After completion:** Auto-resolve any `[NEEDS CLARIFICATION]` markers in tasks.md.
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## [PARALLEL-SYNC] After Steps 8 + 9
> Boss writes a `[PARALLEL-SYNC]` log entry once BOTH Step 8 and Step 9 have returned
> and passed their individual REPORT HARD GATEs. Only then dispatch Step 8b.
---
## STEP 8b — Test Case Generation (Independent QA)
> **Prerequisite:** Step 8 (DD file) AND Step 9 (tasks.md) must both be complete.
| Key | Value |
|-----|-------|
| Agent | `okr.testkit` |
| Model | `claude-sonnet-4-6` |
| Mode | `gen-testcases` |
| Input | `docs/output/ipa-docs/srs/srs-<MOD-ID>-<short-name>.md`, `docs/output/ipa-docs/bd/bd-<MOD-ID>-<short-name>.md`, `docs/output/ipa-docs/dd/dd-<MOD-ID>-<short-name>.md`, `spec.md`, `plan.md` |
| Output | `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<short-name>.md` |
| Report | `reports/08b-testcases-report.md` |
| Gate | REPORT HARD GATE + Boss Validation |
**Delegation `$ARGUMENTS`:**
```
gen-testcases <feature-id>
```
Also pass `pipeline-context` path so testkit can discover all input document paths.
**Boss Validation (after completion):**
- Every FEA-xxx in SRS has ≥ 1 test case
- Every BR-xxx has ≥ 1 normal + 1 abnormal + 1 boundary test case
- Every SCR-MOD-xx-nn in BD has ≥ 1 layout + 1 functional E2E test case
- Test case count > 0 for each category (UT, AT, E2E, IT)
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
.claude/agents/steps/steps-10-12-implement.md
+139
View File
@@ -0,0 +1,139 @@
# Steps 10–12: Implementation & QA Phase
> Boss MUST read this file before executing Steps 10–12.
> Protocols referenced: `protocols/gate-retry-protocol.md`, `protocols/report-gate-protocol.md`, `protocols/implement-delegation.md`
---
## STEP 10 — Implementation + Build & Fix (Auto-Retry)
| Key | Value |
|-----|-------|
| Agent | `speckit.implement` |
| Model | `gpt-5-3-codex` |
| Input | `tasks.md`, `plan.md`, `data-model.md`, `contracts/`, `docs/output/ipa-docs/testcase/testcase-<mod-id>-<short-name>.md` |
| Report | `reports/10-implement-report.md` (NN=10, phase=implement) |
| Gate | BUILD GATE (Auto-Retry) + REPORT HARD GATE (+ "Test Results" + "Screen Verification" sections required) |
| Max retries | 5 |
**Delegation:** Per `protocols/implement-delegation.md` § STEP 10.
**Additional context:**
```yaml
feature-id: <feature-id>
module-id: <mod-id>
report-nn: 10
report-phase: implement
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
```
**Phase 1 — Gen test:**
- Every source file under `src/` must have a dedicated test file under `test/` or co-located (following standard TypeScript/Jest testing conventions)
- All checklist items in `docs/output/specs/<feature-id>/checklists/` must be resolved before proceeding
- Auto-resolve any checklist ambiguities per `protocols/auto-resolve-protocol.md`
**⛔ Test Quality Mandate (Post-Mortem P-08):**
- Integration tests MUST use real database (SQLite for local, Docker DB for CI) — **in-memory mocks are PROHIBITED**
- Every endpoint test MUST verify: HTTP status, response shape, actual DB state change (read-back after write)
- Authorization tests MUST verify: unauthenticated → 401, wrong role → 403, ownership violation → 403
- Pseudo-tests (tests that always pass, mock everything, or have no assertions) are treated as CRITICAL review failure
**Phase 2 — Implement:**
- Execute all tasks in `docs/output/specs/<feature-id>/tasks.md` phase by phase
- All checklist items in `docs/output/specs/<feature-id>/checklists/` must be resolved before proceeding
- Auto-resolve any checklist ambiguities per `protocols/auto-resolve-protocol.md`
**Phase 3 — Build & Fix:**
1. Fix all compile/lint errors (`get_errors` → fix → repeat until zero)
2. Build frontend: `cd frontend && npm install && npm run build`
3. Start Docker (if `docker-compose.dev.yml` exists): `docker compose -f docker/docker-compose.dev.yml up -d`
4. Build backend: `cd backend && npm install && npm run build`
5. Verify startup (if Docker available): `cd backend && npm run start:dev`
**Gate logic:**
- ✅ Build succeeds + app starts → proceed to Step 11
- ❌ Build/startup fails → **Auto-Retry Loop:**
1. Capture error log
2. Write `[ISSUE]` in boss log
3. Invoke `speckit.implement`: *"Fix build/startup errors: <error log>. Minimal fix."*
4. Retry build sequence
5. If retry > 5: `[ESCALATION]`, mark PARTIAL COMPLETE
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 11 — Code Review (Auto-Retry)
| Key | Value |
|-----|-------|
| Agent | `okr.reviewcode` |
| Model | `claude-sonnet-4-6` |
| Input | Implemented source code, spec, tasks, constitution |
| Report | `reports/11-review-code-report.md` |
| Gate | REVIEW GATE (Auto-Retry) + REPORT HARD GATE |
| Fix agent | `speckit.implement` |
| Max retries | 5 |
**Gate logic:**
- ✅/⚠️ → proceed to Step 12
- ❌ REJECTED → invoke `speckit.implement` to fix CRITICAL issues → re-invoke `okr.reviewcode`
- Escalation after 5 retries → continue to Step 12
**Additional DB Data Check:**
Code review MUST also verify:
- All screen data is fetched from the database (via Prisma Client / API endpoints), NOT from mock/hardcoded data
- Prisma seed script (`backend/prisma/seed.ts`) includes necessary seed data for the screens to display real content
- Frontend components call real API endpoints (not mock adapters or static JSON)
- If mock data is detected, mark as ❌ CRITICAL and instruct fix agent to replace with DB-backed data
> ⛔ **[REPORT GATE]** per `protocols/report-gate-protocol.md`
---
## STEP 12 — Final QA Audit: Test Execution (Independent QA)
| Key | Value |
|-----|-------|
| Agent | `okr.testkit` |
| Model | `claude-sonnet-4-6` |
| Mode | `run-tests` |
| Prerequisite | Step 10 PASSED |
| Report (Phase C) | `reports/12-testkit-report.md` |
| Report (Phase D) | `docs/output/ipa-docs/testreport/testreport-<MOD-ID>-<short-name>.md` |
| Gate | TEST GATE (BACK-TO-PLAN on FAIL) |
> ⚠ This is the **FINAL quality gate** before launch. No screen shown until ALL tests pass.
**Delegation `$ARGUMENTS`:**
```
run-tests <feature-id>
```
**Additional delegation context (mandatory):**
Pipeline report (Phase C) MUST include:
1. `## Test Execution Summary` — Category | Total | Passed | Failed | Skipped | Pass Rate
2. `## Failed Test Details` — every failed test with TC-ID, failure reason, design reference
3. `## Retry Log` — Retry Count | Target | Fix Applied | Result
4. `## Screen Verification Results (E2E)` — per-screen accessibility
5. `## Coverage` — Istanbul/c8 metrics
6. `## Overall Verdict` — PASS / FAIL
IPA detail report (Phase D) generation rules:
- Take `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<short-name>.md` as BASE
- Rename title to `Test Execution Result Report`
- Keep ALL test case rows intact — fill `Execution Result`, `Verdict`, `Notes` columns only
- Add `## Test Execution Summary`, `## Coverage Results` at top
- Append `## Screen Verification Results`, `## SRS/BD/DD Compliance Check`, `## Overall Verdict` at bottom
**GATE — FAIL ← BACK TO PLAN (Full Fix Cycle):**
Per `protocols/gate-retry-protocol.md` § BACK-TO-PLAN Fix Cycle:
- ✅ ALL tests PASS + coverage ≥ 80% → proceed to Step 13
- ❌ Tests FAIL → re-invoke pipeline from STEP 6 (max 3 full cycles)
- If 3 cycles exhausted → `[ESCALATION]`, proceed to Step 13 with failure report
> ⛔ **[REPORT GATE]** — **Both files required:**
> 1. `reports/12-testkit-report.md` (Phase C)
> 2. `docs/output/ipa-docs/testreport/testreport-<MOD-ID>-<short-name>.md` (Phase D)