ai-engineering-loop 1.0.10 → 1.0.12

package/adapters/dot/coreview.md

@@ -5,21 +5,34 @@
 In the DOT ecosystem, `@coreview-bot` operates as an external, company-level automated code reviewer attached to GitLab Merge Requests (specifically MRs targeting `develop`).
 
 > [!IMPORTANT]
-> **We do not have access to `@coreview-bot`'s internal rules or heuristics.**
-> - Do not attempt to reverse-engineer or invent Coreview behavior.
-> - Treat Coreview strictly as an external reviewer providing asynchronous critique on GitLab MRs.
-> - Evaluate its comments objectively through the lens of the repository's ground truth.
+> **GATE sebelum Phase 9 (Mattermost Dispatch)**:
+> Dilarang mengirim Mattermost sebelum hasil `glab mr view --comments` **tercetak di pesan ke user**.
+> Jika `comments: 0`, triage kosong tetap wajib dilaporkan sebagai bukti bahwa pengecekan bot telah dilakukan secara riil.
+> 
+> Selalu cetak laporan triage dengan format:
+> ```text
+> Phase 8 Triage
+> MR: !<id>
+> Command: glab mr view <id> --comments
+> Comments: <n>
+> Valid: <list atau none>
+> Halu: <list atau none>
+> Action: <none | fix | reply>
+> ```
 
 ---
 
 ## 2. Coreview Triage Workflow
 
+Mengikuti panduan dari skill `gitlab-mr-feedback` dan `receiving-code-review` (verifikasi teknis menyeluruh sebelum implementasi, tanpa *performative agreement*).
+
 ```mermaid
 flowchart TD
     MRDev[MR Targeting develop Created] --> FetchBot[Fetch Comments via glab mr view --comments]
-    FetchBot --> CheckComments{Bot Comments Found?}
+    FetchBot --> PrintTriage[Print Phase 8 Triage Report to User]
+    PrintTriage --> CheckComments{Bot Comments Found?}
     
-    CheckComments -->|No| Done([Complete Triage])
+    CheckComments -->|No: comments: 0| Done([Complete Triage -> Gate Passed])
     CheckComments -->|Yes| Evaluate{Evaluate Each Comment}
     
     Evaluate -->|VALID: Real Defect| Fix[1. Surgical Code Fix<br>2. Run Tests & Linter<br>3. Commit & Cherry-pick to all branches<br>4. Reply with commit hash]
@@ -63,12 +76,15 @@ Every Coreview comment must be categorized into one of two paths:
      git push origin <branch-name>
      ```
   4. Cherry-pick the new fix commit to all other active environment branches (`main`, `staging`).
-  5. Post a resolution note on GitLab citing the commit hash:
+  5. Post a resolution reply directly **inside the bot's discussion thread**:
      ```bash
-     glab mr note <mr-id> --repo <repo> -m "Fixed in commit <commit-hash>: <technical explanation of the resolution>"
+     # Get discussion_id: glab api "projects/:fullpath/merge_requests/<mr-id>/discussions"
+     glab api "projects/:fullpath/merge_requests/<mr-id>/discussions/<discussion_id>/notes" \
+       -X POST \
+       -F "body=Fixed in commit <commit-hash>: <technical explanation of the resolution>"
      ```
 
-### Case B: Feedback is HALU (False Positive / Hallucinated)
+### Case B: Feedback is HALU (False Positive / Intended Architecture)
 - **Criteria**:
   - The bot suggests calling an API, library method, or hook that does not exist in the codebase or standard library.
   - The bot flags intentional architecture or established framework patterns as "errors".
@@ -76,9 +92,12 @@ Every Coreview comment must be categorized into one of two paths:
   - The bot misinterprets domain-specific business logic already agreed in the Goal Contract.
 - **Action Plan**:
   1. **DO NOT modify any code.**
-  2. Post a polite, evidence-backed technical rebuttal on the GitLab note explaining why the suggestion is invalid:
+  2. Post a polite, evidence-backed technical rebuttal directly **inside the bot's discussion thread**:
      ```bash
-     glab mr note <mr-id> --repo <repo> -m "Feedback is invalid / false positive: <detailed technical explanation with file citations>."
+     # Get discussion_id: glab api "projects/:fullpath/merge_requests/<mr-id>/discussions"
+     glab api "projects/:fullpath/merge_requests/<mr-id>/discussions/<discussion_id>/notes" \
+       -X POST \
+       -F "body=Terima kasih atas masukannya @coreview-bot. <detailed technical explanation with file citations>."
      ```
 
 ---

package/adapters/dot/mattermost.md

@@ -63,40 +63,52 @@ flowchart TD
 
 ---
 
-## 5. Standardized Mattermost Markdown Report Format
+## 5. Standardized Mattermost Markdown Report Format (No AI Slop + Human-Written + PIC at End)
 
-Render separate, ready-to-copy Markdown blocks for every generated Merge Request:
+Render separate, ready-to-copy Markdown blocks for every generated Merge Request using a simple, clean, and punchy format:
 
 ```text
 [MR <ENV_TAG>] <MR_URL>
 Changes log 
-- <Concise change point 1>
-- <Concise change point 2>
-- <Concise change point 3>
+- <Poin 1: Apa yang diperbaiki / fitur apa yang aktif>
+- <Poin 2: Perubahan mekanisme/perilaku sistem secara gamblang>
+- <Poin 3: Proteksi regresi atau pengujian yang ditambahkan>
+
+cc: <PIC>
 ```
 
+### Formatting & Writing Rules (Prinsip `no-ai-slop`):
+- **DILARANG MENGGUNAKAN HEADING MARKDOWN (`#`, `##`, `###`, `####`)**: Gunakan teks polos agar font di Mattermost tidak membesar secara berlebihan.
+- **Format Sederhana Tanpa Metadata Bertele-tele**: Jangan menyertakan tabel metadata yang panjang (seperti Branch, Repo, Status Verifikasi). Cukup link MR dan list `Changes log`.
+- **Sertakan PIC di Akhir Pesan**: Ambil PIC dari file konfigurasi `mattermost-channel-mapping.json`. Jika belum ada, tanyakan kepada user dan simpan ke file mapping. Tambahkan `cc: <PIC>` di baris paling bawah.
+- **Gunakan Bahasa Manusia yang Lugas & Konkret**:
+  - ✅ **Awali dengan kata kerja aktif**: *"Memperbaiki..."*, *"Memigrasikan..."*, *"Menjaga..."*, *"Menambahkan..."*, *"Mengubah..."*.
+  - ❌ **Dilarang kata-kata AI Slop / Puffery**: `secara komprehensif`, `memastikan keakuratan`, `memfasilitasi`, `menyelaraskan alur`, `mengoptimalkan proses`, `solusi yang kokoh/robust`, `meningkatkan efisiensi`, `telah berhasil diimplementasikan`.
+  - ❌ **Dilarang raw code / AST leakage**: Jangan menyebut nama variabel internal atau query mentah (misal `user.type.hasNormalHours`, `attendanceConfirmationPagination Prisma query`). Jelaskan dampak fungsionalnya.
+
 ### Environment Tags:
 - `[MR DEV]`: Merge Request targeting `develop`.
 - `[MR STAGING]`: Merge Request targeting `staging`.
 - `[MR MAIN]` (or `[MR PROD]`): Merge Request targeting `main` / `master`.
 
-### Example Report:
+### Contoh Penerapan Nyata:
+
 ```text
-[MR DEV] https://gitlab.dot.co.id/dot-system/dotify-new/-/merge_requests/948
+[MR DEV] https://gitlab.dot.co.id/playground/bikin-rindu-tools-v2/-/merge_requests/108
 Changes log 
-- Include user.type.hasNormalHours and timeEntities.overtimeNote in attendanceConfirmationPagination Prisma query.
-- Create resolveAttendanceConfirmationDisplayStatus utility to properly evaluate hasPendingTimeEntities by checking overtimeNote, isWeekend, duration > 8, non-normal hours employees, and null statuses.
-- Add comprehensive unit tests in src/server/attendance-confirmations/utils/resolve-display-status.test.ts covering all status permutations.
+- Memperbaiki crash halaman dashboard di Safari setelah login akibat QuotaExceededError pada localStorage.
+- Memigrasikan penyimpanan cache browser ke IndexedDB (idb-keyval) sehingga kapasitas penyimpanan leluasa dan tidak memblokir main thread.
+- Menjaga synchronous script di head untuk preferensi tema agar tidak terjadi kedipan tampilan (FOUC).
+- Menambahkan auto-migration otomatis untuk memindahkan data lama dari localStorage ke IndexedDB sekaligus membebaskan kuota browser.
 
-[MR STAGING] https://gitlab.dot.co.id/dot-system/dotify-new/-/merge_requests/947
-Changes log 
-- Include user.type.hasNormalHours and timeEntities.overtimeNote in attendanceConfirmationPagination Prisma query.
-- Create resolveAttendanceConfirmationDisplayStatus utility to properly evaluate hasPendingTimeEntities by checking overtimeNote, isWeekend, duration > 8, non-normal hours employees, and null statuses.
-- Add comprehensive unit tests in src/server/attendance-confirmations/utils/resolve-display-status.test.ts covering all status permutations.
+cc: @hanaaaca
 
-[MR MAIN] https://gitlab.dot.co.id/dot-system/dotify-new/-/merge_requests/946
+[MR DEV] https://gitlab.dot.co.id/dot-system/dotify-new/-/merge_requests/963
 Changes log 
-- Include user.type.hasNormalHours and timeEntities.overtimeNote in attendanceConfirmationPagination Prisma query.
-- Create resolveAttendanceConfirmationDisplayStatus utility to properly evaluate hasPendingTimeEntities by checking overtimeNote, isWeekend, duration > 8, non-normal hours employees, and null statuses.
-- Add comprehensive unit tests in src/server/attendance-confirmations/utils/resolve-display-status.test.ts covering all status permutations.
+- Mengubah status entitas yang tadinya APPROVED menjadi NEED APPROVAL otomatis saat project atau jam kerjanya diedit.
+- Memperbaiki sinkronisasi worker agar periode absensi berjalan (UNCONFIRMED) tetap diproses saat admin mengedit data.
+- Menjaga entitas lain yang sudah disetujui PM di periode yang sama agar status approval-nya tidak ter-reset.
+- Menambahkan unit test untuk skenario lembur multi-entry harian.
+
+cc: @ulfa.mufida
 ```

package/adapters/dot/skills/dot-dev-skill-router/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: dot-dev-skill-router
+description: Route DOT tasks. Commit-bound bugfix, feature, or refactor uses ai-engineering-loop for Stages 0-7, then dot-dev-workflow for Stage 8 delivery. Do not use dot-dev-workflow as a parallel engineering OS.
+---
+
+# DOT Development Skill Router
+
+Pick the smallest relevant skill. Do not load every skill. **AI Engineering Loop is the engineering OS on DOT repos.** `dot-dev-workflow` is Stage 8 delivery only (GitLab, cherry-pick, Coreview, Mattermost).
+
+## Core rules
+
+1. Read repository instructions and inspect the affected code before choosing a workflow.
+2. For DOT work that will be committed or opened as an MR, load `ai-engineering-loop`. Stage 1 grill includes `task-impact-inquiry` (four pillars). Stages 6-7 are AEL Devil's Advocate and Judge. Do not run the old 9-phase `dot-dev-workflow` as a second loop. Do not run `task-impact-inquiry` as a second interview after grill.
+3. After Judge `PASS`, load `dot-dev-workflow` for Stage 8 delivery only.
+4. Use `ponytail` when the smallest correct solution matters.
+5. Use `dot-verification` before claiming a change is fixed, complete, passing, or ready.
+6. Commits, push, GitLab issue/MR, Mattermost, deploys, database mutation, and deletion are explicit user-requested side effects. `auto-mr-issue` is never automatic.
+7. Do not invent APIs, test results, design tokens, or behavior. Report blockers as blockers.
+
+## Route by task
+
+| Task | Load in order |
+|---|---|
+| DOT bugfix / feature / refactor that will be committed or opened as MR | `ai-engineering-loop` (grill includes `task-impact-inquiry`; DA + Judge before commit) → `dot-dev-workflow` Stage 8 after Judge PASS |
+| Impact / blast-radius question only (no implementation) | `task-impact-inquiry` |
+| New feature, product/UI behavior unclear | `brainstorming` → `product-contract-analysis` → then `ai-engineering-loop` if it will be built |
+| Legacy FE + BE module documentation | `generate-module-fsd` |
+| Raw `.fig` file to standalone HTML + Tailwind | `fig-to-tailwind-extractor`; add `figma-token-extractor` for token/visual-contract audit |
+| New landing page or visual redesign | `frontend-design` + `design-taste-frontend`; add `ui-ux-pro-max` only for a targeted UI decision |
+| UI/accessibility/design review | `web-design-guidelines`; add `ui-ux-pro-max` for focused UX, stack, typography, or interaction guidance |
+| DOT API contract or OpenAPI change | `ai-engineering-loop` → `dot-openapi-contract` → `dot-verification` |
+| DOT backend behavior/API regression coverage | `ai-engineering-loop` → `dot-api-test` → `dot-verification` |
+| Backend architecture, clean code, naming, or query optimization | `ai-engineering-loop` → `backend-development` (during Maker) → `dot-verification` |
+| Backend action, queue, worker, or entity status recalculation | `ai-engineering-loop` → `backend-development` + `backend-safety-guardrails` (during Maker) → `dot-verification` |
+| Local web app repro, browser smoke, or UI regression | `webapp-testing` → `dot-verification` |
+| Plan execution with review checkpoints | `executing-plans` → `ai-engineering-loop` |
+| Pre-merge review after AEL already ran | AEL Judge verdict is the gate. Do not re-run skill `devils-advocate` unless Judge was skipped |
+| Code review feedback reception | `receiving-code-review` |
+| GitLab MR discussions / feedback resolution | `gitlab-mr-feedback` → `receiving-code-review` |
+| Broad creative/product ideation | `creative-ideation`; use `brainstorming` when the next outcome must be an approved plan |
+| Explicit post-commit GitLab issue/MR request | `auto-mr-issue` after the user explicitly asks for it |
+
+## Workflow gates
+
+- Goal Contract (with seams and, on DOT, impact matrix) before production edits.
+- Before `git commit` / `glab mr create`: AEL Judge `PASS`. Considering risks while coding is not that gate.
+- Before Mattermost: `glab mr view --comments` printed to the user, even when comment count is 0.
+- For final reports, separate verified, failed, blocked, and untested items.
+
+## Avoid
+
+- Do not run `dot-dev-workflow` Phases 1-6 when `ai-engineering-loop` is available.
+- Do not chain `task-impact-inquiry` then a full second engineering loop.
+- Do not invoke `auto-mr-issue` merely because code was committed.
+- Do not use the full delivery pipeline for a tiny local question unless the user asked to ship.

package/adapters/dot/skills/dot-dev-workflow/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: dot-dev-workflow
+description: DOT Stage 8 delivery after AI Engineering Loop Judge PASS. GitLab issue/MR, multi-branch cherry-pick, Coreview triage, Mattermost. Not a substitute for ai-engineering-loop.
+---
+
+# DOT Delivery Workflow (Stage 8)
+
+This is **not** the engineering OS. On DOT repositories:
+
+1. Run **`ai-engineering-loop`** for Stages 0-7 (grill, RCA, Maker, verification, Devil's Advocate, Judge).
+2. Run **this skill only after Judge `PASS`** (or the user explicitly asked to ship).
+3. Stage 1 grill already includes `task-impact-inquiry`. Do not interview again.
+4. Stages 6-7 are AEL DA + Judge. Do not re-run skill `devils-advocate` as a second pre-commit OS.
+
+If `ai-engineering-loop` is missing on this host, say so and stop. Do not silently run the old 9-phase loop.
+
+## Mapping (old phases → AEL)
+
+| Old `dot-dev-workflow` | Now |
+|---|---|
+| Phase 1 RCA | AEL Stage 2 (`core/root-cause-analysis.md`) |
+| Phase 2 impact inquiry | AEL Stage 1 grill + `task-impact-inquiry` |
+| Phase 3-5 code / tests / tsc | AEL Stages 4-5 (`policies/tdd-policy.md`, `.ai-engineering-loop/verification.md`) |
+| Phase 6 `devils-advocate` | AEL Stages 6-7 (Finding Ledger + Judge PASS/ITERATE/ESCALATE) |
+| Phase 7-9 glab / Coreview / Mattermost | **This skill** (AEL Stage 8). Prefer `adapters/dot/` in the AEL package when present. |
+
+`git commit`, `git push`, and `glab mr create` are forbidden until Judge `PASS`.
+
+## DOT Maker constraints (AEL Stage 4)
+
+While AEL Maker runs, still enforce:
+
+- `backend-development` for naming, queries, layering.
+- `backend-safety-guardrails` on mutations, jobs, recalculation: never bypass BullMQ; scope by entity id not coarse date strings; never overwrite `APPROVED`/`REJECTED` without explicit force; BigInt as string across boundaries; container moves sync old and new parents.
+- Tests: `npx jest --testPathIgnorePatterns="dotify-api"` unless `.ai-engineering-loop/verification.md` says otherwise.
+- Branch from a clean target (`main`, `staging`, or `develop`), then `git checkout -b <type>/<descriptive-name>`.
+
+Print these six invariants before commit (N/A allowed only with one sentence citing the diff):
+
+- Queue: BullMQ not bypassed
+- Granularity: entity id, not grouping strings
+- BigInt: string in payloads, compare as BigInt
+- Manual review: APPROVED/REJECTED not auto-reset
+- Container move: old and new parents synced
+- Hygiene: no unused locals or dead imports
+
+---
+
+## Stage 8a — Multi-branch MR and issue card (`glab`)
+
+If the workspace has `adapters/dot/gitlab.md` and `adapters/dot/multi-branch.md`, follow those. Otherwise:
+
+1. Commit:
+
+```bash
+git add <modified-files>
+git commit -m "<type>(<scope>): <summary>"
+```
+
+2. Create a GitLab issue if none is linked (`glab issue create` with module title, scope checkboxes, testing steps, expectation table, label `Ready to Test`).
+
+3. Create the base MR (`glab mr create` onto the target branch, description links the issue).
+
+4. Propagate to `staging` and `develop`: fetch, branch from origin, cherry-pick the commit, re-run verification, push, open MR per environment.
+
+---
+
+## Stage 8b — Coreview and MR discussions
+
+Follow `adapters/dot/coreview.md` when present, plus `gitlab-mr-feedback` and `receiving-code-review`.
+
+Gate before Mattermost: run `glab mr view <id> --comments` and print the triage. `comments: 0` is a printed empty triage, not a skip.
+
+```text
+Phase 8 Triage
+MR: !<id>
+Command: glab mr view <id> --comments
+Comments: <n>
+Valid: <list or none>
+Halu: <list or none>
+Action: <none | fix | reply>
+```
+
+Reply **inside** the Coreview discussion thread (not a top-level note):
+
+```bash
+glab api "projects/:fullpath/merge_requests/<mr-id>/discussions"
+glab api "projects/:fullpath/merge_requests/<mr-id>/discussions/<discussion_id>/notes" -X POST -F "body=<text>"
+```
+
+- VALID: fix surgically, re-verify, commit, propagate, reply with commit hash.
+- HALU: do not change code; reply with file-cited technical pushback.
+
+---
+
+## Stage 8c — Mattermost (`no-ai-slop`)
+
+Follow `adapters/dot/mattermost.md` when present.
+
+1. Resolve channel and PIC from `/Users/egagofur/.gemini/config/mattermost-channel-mapping.json`. If PIC is missing, ask the user and save it.
+2. Send via MCP `mattermost_send_message` with `from: "AI Agent"`. Use the Mattermost CLI only if MCP fails. Do not send twice.
+3. Put `cc: <PIC>` on the last line.
+
+Format (plain text, no markdown headings):
+
+```text
+[MR <ENV_TAG>] <MR_URL>
+Changes log
+- <active-voice change>
+- <what the system now does>
+- <regression protection>
+
+cc: <PIC>
+```
+
+ENV tags: `[MR DEV]` develop, `[MR STAGING]` staging, `[MR MAIN]` / `[MR PROD]` main.
+
+Forbidden: puffery (`secara komprehensif`, `robust`, `mengoptimalkan proses`), raw code/AST in the report.

package/agents/devil-advocate.md

@@ -31,7 +31,7 @@ Canonical ids are listed first; skill aliases are in parentheses.
 
 The Devil's Advocate receives **only** the objective artifact package:
 - `Goal Contract` (AC-1..N, constraints, out of scope).
-- `Project Context` (`.ai-engineering-loop/`: `architecture.md`, `conventions.md`, `verification.md`).
+- `Project Context` (`.ai-engineering-loop/`: `architecture.md`, `conventions.md`, `verification.md`, `glossary.md`).
 - `Pure Git Diff` (`git diff <base>...HEAD`).
 - `Deterministic Verification Logs` (exit code 0 proof).
 - `Prior Finding Signatures`.
@@ -52,6 +52,8 @@ The Devil's Advocate outputs a strictly structured Finding Ledger:
   "findings": [
     {
       "id": "DA-01",
+      "axis": "spec",
+      "hardConvention": false,
       "topic": "correctness",
       "validity": "VALID",
       "severity": "BLOCKER",

package/agents/maker.md

@@ -7,10 +7,9 @@ The **Maker Agent** is the builder and execution engine of the AI Engineering Lo
 ```mermaid
 flowchart LR
     GoalContract[Goal Contract] --> Maker[Maker Agent]
-    Maker --> DeepAnalysis[1. Root Cause & Data Flow Analysis]
-    DeepAnalysis --> SurgicalCode[2. Surgical Code Implementation]
-    SurgicalCode --> ComprehensiveTests[3. Boundary & Unit Tests]
-    ComprehensiveTests --> DeterministicRun[4. Deterministic Verification]
+    Maker --> DeepAnalysis[1. Root Cause (core/root-cause-analysis.md)]
+    DeepAnalysis --> RedGreen[2. TDD at agreed seams]
+    RedGreen --> DeterministicRun[3. Deterministic Verification Evidence]
 ```
 
 ---
@@ -26,9 +25,10 @@ flowchart LR
    - Maintain strict adherence to existing codebase architecture, design system tokens, naming conventions, and file organization.
    - Avoid speculative abstractions, unsolicited refactoring, or touching out-of-scope files.
    - Leave zero dead code, zero stubs, zero empty catch blocks, and zero speculative TODOs.
-3. **Comprehensive Test Engineering**:
-   - Author automated unit, integration, or schema test suites alongside the modified code.
-   - Cover normal positive execution, negative edge cases, null/undefined safety, empty payloads, boundary conditions, and business rule permutations.
+3. **Test-Driven Engineering** ([TDD Policy](file:///Users/egagofur/Development/work/ai-engineering-loop/policies/tdd-policy.md)):
+   - Red before green at the Goal Contract's named seams only.
+   - Tests observe public behavior, use glossary terms, and never assert implementation details.
+   - Cover the AC slice in play: happy path, negative edge, null/empty, boundary. Vertical slices, not all-tests-then-all-code.
 4. **Addressing Reviewer Findings**:
    - In subsequent iterations, ingest findings from the [Devil's Advocate](file:///Users/egagofur/Development/work/ai-engineering-loop/agents/devil-advocate.md) and directives from the [Judge](file:///Users/egagofur/Development/work/ai-engineering-loop/agents/judge.md).
    - Fix validated issues surgically.
@@ -48,13 +48,15 @@ flowchart LR
 ## 4. Execution Workflow
 
 ### Step 1: Pre-Code Analysis
+- Follow [Root Cause Analysis](file:///Users/egagofur/Development/work/ai-engineering-loop/core/root-cause-analysis.md). For bugs: red repro before a production edit.
 - Map the data flow across layers.
+- Confirm seams from the Goal Contract. Use `.ai-engineering-loop/glossary.md` for names.
 - Check git history for recent changes to the affected files.
-- Identify edge cases and boundary conditions before typing code.
 
-### Step 2: Implementation & Tests
-- Implement the minimal fix or feature logic.
-- Write corresponding automated tests in accordance with project test frameworks.
+### Step 2: Red-Green at Seams
+- One failing test at a named seam, then the smallest production change that passes it.
+- Do not test private helpers. Do not write tautological assertions.
+- Refactoring is out of this loop unless the Goal Contract listed it.
 
 ### Step 3: Run Deterministic Verification
 - Run test commands: `npx jest`, `pytest`, `cargo test`, `go test`, etc.

package/agents/shared/devil-advocate.body.md

@@ -0,0 +1,61 @@
+You are the Devil's Advocate for the AI Engineering Loop. You are read-only. You never modify application source and never commit.
+
+## Budget (hard stop)
+
+Finish in at most 8 tool calls, then emit the Finding Ledger. Do not explore the rest of the repo. Do not spawn children. Do not run git log.
+
+## Input barrier
+
+Use only:
+
+1. The diff file path in the spawn prompt. Read that file first. Do not run git diff if a diff path was given.
+2. Goal Contract path (if given).
+3. Verification log path (if given).
+4. conventions.md path (if given). At most one extra read.
+5. At most 8 source files that appear as paths in the diff.
+
+Skip: `*.css`, files named like `*-css.ts` or `report-css.ts`, generated/vendor dirs, and any file where the diff hunk already contains enough evidence. Prefer quoting the hunk over opening the whole file.
+
+Do not ask for Maker rationale.
+
+## Two axes (do not merge)
+
+Report Spec and Standards as separate findings. Do not rerank one axis with the other. A change can pass Spec and fail Standards, or the reverse. Do not spawn children to split axes.
+
+**Spec** (`axis: "spec"`): Goal Contract acceptance criteria, correctness, error handling, security, concurrency, tests that fail to prove an AC. BLOCKER or HIGH only for a real AC breach or runtime defect.
+
+**Standards** (`axis: "standards"`): `.ai-engineering-loop/conventions.md` plus the smell baseline below. Judgement calls: severity MEDIUM or LOW. Set `hardConvention: true` only when conventions.md states a hard rule that this hunk violates. A smell that hides an AC defect is Spec, not Standards.
+
+Skip style nits unless they hide a defect.
+
+Smell baseline (judgement only; skip if tooling already enforces; repo conventions override): Mysterious Name; Duplicated Code; Feature Envy; Data Clumps; Primitive Obsession; Repeated Switches; Shotgun Surgery; Divergent Change; Speculative Generality; Message Chains; Middle Man; Refused Bequest.
+
+## Output
+
+Return a Finding Ledger as a fenced JSON block and stop:
+
+```json
+{
+  "iteration": 1,
+  "executionMode": "TRUE_INDEPENDENT_AGENT",
+  "findings": [
+    {
+      "id": "DA-01",
+      "axis": "spec",
+      "hardConvention": false,
+      "topic": "correctness",
+      "validity": "VALID",
+      "severity": "BLOCKER",
+      "disposition": "STRONG",
+      "location": "path/to/file.ext#L12-L20",
+      "acceptanceCriteria": "AC-1",
+      "failureScenario": "Concrete failing case",
+      "reproduction": "Steps to reproduce",
+      "evidence": "Hunk or line you read",
+      "concreteAlternativeDiff": "diff snippet"
+    }
+  ]
+}
+```
+
+Rules: axis is spec or standards (default spec). hardConvention is boolean, default false. validity VALID or INVALID; severity BLOCKER, HIGH, MEDIUM, or LOW; disposition STRONG, ACCEPTABLE, or WEAK. VALID BLOCKER or HIGH must include concreteAlternativeDiff. Empty findings is allowed.

package/agents/shared/judge.body.md

@@ -0,0 +1,38 @@
+You are the Judge for the AI Engineering Loop. You do not write application code. You issue one verdict: PASS, ITERATE, or ESCALATE.
+
+## Budget (hard stop)
+
+Finish in at most 4 tool calls, then emit the verdict. Read the Finding Ledger and Goal Contract first. Open source only to fact-check a location the ledger already cited. Do not re-review the whole diff. Do not run git log. Do not spawn children. Skip `*.css`, `*report-css*`, and generated/vendor files.
+
+## Inputs
+
+Use only paths in the spawn prompt: Goal Contract, verification evidence, Finding Ledger. Ignore Maker optimism and reviewer tone. Disposition never overrides Validity plus Severity.
+
+## Axes
+
+Do not merge Spec and Standards into one ranking.
+
+- Spec VALID BLOCKER or HIGH (or missing axis, treated as spec): ITERATE (ESCALATE if iteration is 3 or more)
+- Standards VALID BLOCKER or HIGH: ITERATE only when hardConvention is true
+- Other Standards findings: ACCEPT as tradeoff; may still PASS
+- INVALID findings: DISMISS, cannot block delivery
+- VALID MEDIUM or LOW: ACCEPT as tradeoff; may still PASS
+- Verification missing, vague, or non-zero exit: ITERATE
+- All acceptance criteria proven, verification green, zero open blockers: PASS
+
+## Output
+
+Return a fenced JSON block:
+
+```json
+{
+  "verdict": "PASS",
+  "reason": "All acceptance criteria verified; 0 open blocking findings",
+  "action": "Proceed to context impact assessment and delivery adapter",
+  "blockingFindings": [],
+  "acceptableTradeoffs": [],
+  "dismissedFindings": []
+}
+```
+
+`verdict` must be exactly PASS, ITERATE, or ESCALATE. Do not edit source.