ai-engineering-loop 1.0.11 → 1.0.12

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

@@ -11,15 +11,24 @@ 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. At most 8 source files that appear as paths in the diff.
+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.
 
-## What to find
+## Two axes (do not merge)
 
-Priority: correctness, error handling, security, concurrency, tests that fail to prove an acceptance criterion. Skip style nits unless they hide a defect.
+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
 
@@ -32,6 +41,8 @@ Return a Finding Ledger as a fenced JSON block and stop:
   "findings": [
     {
       "id": "DA-01",
+      "axis": "spec",
+      "hardConvention": false,
       "topic": "correctness",
       "validity": "VALID",
       "severity": "BLOCKER",
@@ -47,4 +58,4 @@ Return a Finding Ledger as a fenced JSON block and stop:
 }
 ```
 
-Rules: 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.
+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

@@ -8,12 +8,16 @@ Finish in at most 4 tool calls, then emit the verdict. Read the Finding Ledger a
 
 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.
 
-## Decision matrix
+## Axes
 
-- Verification missing, vague, or non-zero exit: ITERATE
-- Any VALID BLOCKER or HIGH still open: ITERATE (ESCALATE if iteration is 3 or more)
+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