@eltonssouza/development-utility-kit 1.0.0

package/dashboard/public/content/docs/architecture-overview.en.md

@@ -0,0 +1,260 @@
+# Architecture overview
+
+The development-utility-kit is a harness for fullstack development with Claude Code and Cowork. The architecture is **deliberately simple**: two functional layers (Skills + Agents), a single entry point (the Skill that matches the prompt), and a cross-cutting Hooks layer that intercepts tools and prompts.
+
+There is no command layer. The `commands/` layer was removed on 2026-05-25 and replaced by the catch-all Skill `project-manager`, which routes any prompt without a specific skill to the correct specialist agent.
+
+This document describes the mental model you need to understand why a prompt about "create endpoint" ends up executing code in `backend-developer`, or why a request to "run sprint 3" dispatches `qa-engineer`, `backend-developer`, `frontend-developer`, and `gate-keeper` in parallel.
+
+## Macro model
+
+```
+                ┌──────────────────────────────────────────┐
+                │  USER PROMPT                             │
+                │  "create endpoint for product signup"    │
+                └────────────────────┬─────────────────────┘
+                                     │
+                                     ▼
+            ┌────────────────────────────────────────────┐
+            │ UserPromptSubmit hook                      │
+            │ scripts/hooks/prompt-gate-reminder.sh      │
+            │ injects [HONCHO MEMORY] + gate reminders   │
+            └────────────────────┬───────────────────────┘
+                                 │
+                                 ▼
+            ┌────────────────────────────────────────────┐
+            │ SKILL MATCHER (Cowork / Claude Code)       │
+            │ matches keywords against description: of   │
+            │ skills in .claude/skills/<slug>/SKILL.md   │
+            └────────────────────┬───────────────────────┘
+                                 │
+                ┌────────────────┴────────────────┐
+                │                                 │
+                ▼                                 ▼
+   specific skill matched          no specific skill matched
+   e.g. run-sprint, grill-me,      ▼
+   bootstrap-fullstack             project-manager (catch-all)
+                │                  picks ONE specialist agent
+                │                  from the routing table
+                ▼                                 │
+                └─────────────────┬───────────────┘
+                                  ▼
+            ┌────────────────────────────────────────────┐
+            │ AGENT DISPATCH                             │
+            │ Skill calls Task(subagent_type="<agent>")  │
+            │ Agent runs on declared model:              │
+            │ Opus (decision) / Sonnet (impl) / Haiku    │
+            └────────────────────┬───────────────────────┘
+                                 │
+                                 ▼
+            ┌────────────────────────────────────────────┐
+            │ Agent tool calls (Read/Edit/Bash/Write)    │
+            │ PreToolUse hooks block dangerous actions   │
+            │ PostToolUse hooks run prettier + reminder  │
+            └────────────────────┬───────────────────────┘
+                                 │
+                                 ▼
+            ┌────────────────────────────────────────────┐
+            │ gate-keeper agent validates thresholds     │
+            │ Stop hook reminds brain-keeper             │
+            │ SubagentStop hook records telemetry        │
+            └────────────────────────────────────────────┘
+```
+
+## Layer 1 — Skills
+
+Skills are the **single entry point** of the harness. Each Skill lives at `.claude/skills/<slug>/SKILL.md` with YAML frontmatter describing when it triggers:
+
+```yaml
+---
+name: run-sprint
+description: |
+  Triggers when the user says "run sprint X", "execute the sprint",
+  "rodar sprint 3", or any phrase asking to execute a sprint from
+  docs/plans/PLAN_*.md. Owns the orchestration of sprint execution
+  with checkpoints and parallel delegation.
+---
+```
+
+The Cowork classifier (and the Claude Code matcher) reads the `description` field of each skill and automatically picks the skill that best matches the user prompt. You do not have to invoke the skill manually — just describe the task.
+
+To force a specific skill, use `/skill <name>` in Claude Code or mention it explicitly: `use the analyst skill`.
+
+### Skill types
+
+- **Orchestration skills**: `run-sprint`, `grill-me`, `bootstrap-fullstack`, `auto-test-guard`, `prd-ready-check`. They have multiple stages with checkpoints (⏸️) and map each stage to an agent.
+- **Routing skills**: `project-manager`. Catch-all fallback that analyzes the prompt and dispatches to ONE specialist agent via Task tool.
+- **Passive skills**: `caveman` (telegraphic style, always active), `honcho-memory` (persistent memory, injects `[HONCHO MEMORY]` into every prompt via hook).
+- **Product skills**: `to-prd`, `to-issues`. Convert artifacts between pipeline stages.
+- **Adoption skills**: `update-template`, `active-project`. Synchronize projects with the latest harness version.
+
+The complete skill table lives in [Skills reference](skills-reference).
+
+## Layer 2 — Agents
+
+Agents are the **specialized executors** per domain. Each agent lives at `.claude/agents/<name>.md` with frontmatter declaring:
+
+```yaml
+---
+name: backend-developer
+description: |
+  Implements Java 25 + Spring Boot 4 backend code — controllers,
+  services, DTOs, repositories, security configuration. Delegated to
+  by sprint-runner and project-manager.
+tools: Read, Edit, Write, Bash, Grep, Glob
+model: claude-sonnet-4-6
+---
+```
+
+The `model:` field is mandatory. The model-per-agent rule (defined in `CLAUDE.md`):
+
+| Model | When to use | Agents |
+|---|---|---|
+| **Opus 4.7** | Irreversible decision, macro technical veto | `product-owner`, `tech-lead`, `security-engineer` |
+| **Sonnet 4.6** | Implementation, decomposition, review, test, UI, recording | `architect`, `analyst`, `backend-developer`, `frontend-developer`, `mobile-developer`, `n8n-specialist`, `ux-designer`, `database-engineer`, `devops-engineer`, `qa-engineer`, `code-reviewer`, `gate-keeper`, `test-coverage-auditor`, `prd-ready-check`, `api-integration-test`, `sprint-runner`, `brain-keeper`, `auditor`, `release-engineer`, `migrator` |
+| **Haiku 4.5** | Scaffold, template, mechanical sync | `scaffold`, `update-template` |
+
+Invocation happens via the Task tool, inside a Skill:
+
+```text
+Task(
+  subagent_type="backend-developer",
+  description="Implement product controller",
+  prompt="Implement POST /api/v1/products per PLAN_product.md, Sprint 1, task T2..."
+)
+```
+
+A Skill can dispatch multiple agents in parallel (when there is no dependency) or in series (when one agent's output feeds the next). This is the Skill's responsibility, not the agents'.
+
+The complete agent table lives in [Agents reference](agents-reference).
+
+## Passive skills (always on)
+
+Two skills run silently on every prompt without needing a keyword match:
+
+### caveman
+
+Output style skill. Reduces tokens by 65-75% by dropping articles, filler, and pleasantries. Modes:
+
+- `caveman ultra` — code (default for code).
+- `caveman full` — markdown `.md` (default for `.md`).
+- `caveman lite` — contracts / PRDs (more explanatory).
+- `stop caveman` — turns it off.
+
+### honcho-memory
+
+Persistent cross-session memory skill via Honcho v3 self-hosted. On every prompt, it injects a `[HONCHO MEMORY]` block containing:
+
+- **Peer-scoped**: explicit and inferred user preferences (e.g. "prefers bash over PowerShell", "works on CockroachDB").
+- **Session-scoped**: current project context (e.g. "feature in progress: product signup").
+
+Injection happens via the `UserPromptSubmit` hook calling `prompt-gate-reminder.sh`, which fetches the memory from Honcho and prepends it to the prompt before the model receives it. If Honcho is offline, the skill degrades gracefully — the prompt proceeds without the block. Details in [Honcho memory](honcho-memory).
+
+## Hooks layer (cross-cutting)
+
+Hooks live in `.claude/settings.json` and dispatch scripts in `scripts/hooks/`. They are synchronous interceptors that run before or after tools, prompts, or responses:
+
+| Hook | Matcher | Script | Function |
+|---|---|---|---|
+| `PreToolUse` | `Bash` | `pre-push-guard.sh` | Blocks `git push` directly to `main`/`develop` |
+| `PreToolUse` | `Bash` | `block-test-deletion.sh` | Blocks `rm` commands on test files |
+| `PostToolUse` | `Edit\|MultiEdit\|Write` | inline (prettier) | Formats `.ts`/`.tsx`/`.html`/`.scss`/`.css` after edit |
+| `PostToolUse` | `Edit\|MultiEdit\|Write` | `post-edit-test-reminder.sh` | Reminds to run tests after edits in production code |
+| `UserPromptSubmit` | `*` | `prompt-gate-reminder.sh` | Injects `[HONCHO MEMORY]` + senior+ gate reminder |
+| `Stop` | `*` | `stop-brain-reminder.sh` | Reminds to invoke `brain-keeper` at end of a PLAN |
+| `Notification` | `*` | inline (notify-send / osascript) | Notifies desktop when Claude needs attention |
+
+Full details in [Hooks reference](hooks-reference).
+
+## Canonical directories
+
+```
+project/
+├── .claude/
+│   ├── agents/              agents — domain executors (.md)
+│   ├── skills/              skills — entry points (one folder each)
+│   ├── settings.json        permissions + hooks configuration
+│   └── honcho/              local Honcho memory configuration
+│
+├── docs/
+│   ├── brain/               Obsidian vault (daily, features, decisions, bugs, tech-debt, MOC)
+│   │   └── .obsidian/       Obsidian config (with per-folder color snippet)
+│   ├── plans/               PLAN_*.md generated by analyst
+│   ├── prd/                 PRD_*.md generated by to-prd
+│   ├── discovery/           DISCOVERY_*.md generated by grill-me
+│   ├── issues/              ISSUES_*.md generated by to-issues
+│   └── decisions/           ADR-NNN-<slug>.md (Architecture Decision Records)
+│
+├── dashboard/               local interface (Vite + Vue) for telemetry + docs
+│   └── public/content/docs/ the docs you are reading now
+│
+├── scripts/
+│   ├── hooks/               hooks invoked by .claude/settings.json
+│   ├── new-project.bat      Windows interactive wrapper
+│   ├── new-project.sh       bash interactive wrapper
+│   ├── lint-harness.sh      structural lint of the harness
+│   └── verify-integrity.sh  verifies that .claude/ is consistent
+│
+├── backend/                 Java 25 + Spring Boot 4 code (when type=backend|fullstack)
+├── frontend/                Angular 21 code (when type=frontend|fullstack)
+└── CLAUDE.md                source of truth — instructions for Claude in the project
+```
+
+## Prompt → response flow (step by step)
+
+Follow what happens when you type `"create endpoint for product signup"`:
+
+1. **UserPromptSubmit hook** fires — `prompt-gate-reminder.sh` calls Honcho via HTTP, gets relevant memory, prepends `[HONCHO MEMORY]` to the prompt.
+2. **Skill matcher** analyzes the enriched prompt. No specific orchestrator skill keyword → falls into `project-manager` (catch-all).
+3. **project-manager** reads the prompt, consults the routing table, decides: "backend implementation" → picks `backend-developer`.
+4. **Task tool** dispatches `backend-developer` (Sonnet 4.6 model) with the full prompt + PLAN/PRD context if any.
+5. **backend-developer** executes: reads CLAUDE.md, consults the PLAN, picks the package (`com.company.product.web`), generates controller + DTOs + service + Flyway migration.
+6. **PreToolUse hooks** run on each Bash: `pre-push-guard` blocks push to main; `block-test-deletion` blocks `rm` on tests.
+7. **PostToolUse hooks** run on each Edit/Write: prettier formats the file; `post-edit-test-reminder` reminds the agent to invoke `qa-engineer`.
+8. **gate-keeper** (called by the `auto-test-guard` skill at the end) runs JaCoCo coverage, PIT mutation, ESLint, Lighthouse. If any threshold fails, it blocks.
+9. **Stop hook** fires `stop-brain-reminder.sh` reminding `brain-keeper` to record the feature in the Obsidian vault.
+10. **SubagentStop hook** (future/optional) records telemetry per agent in `dashboard/data/telemetry.json` via `telemetry-writer.js`.
+
+## Cowork and Claude Code CLI integration
+
+Both Cowork desktop and Claude Code CLI consume the same `.claude/` from the project. This means:
+
+- Skills created in the harness work in both environments with no modification.
+- Hooks declared in `.claude/settings.json` only work where the runtime supports hooks (Claude Code CLI has full support; Cowork has partial support depending on version).
+- Permissions declared in `.claude/settings.json > permissions.allow` are respected by both.
+
+Rule of thumb: **if Cowork alone covers it, use Cowork**. If you need bash hooks, terminal, or CI automation, use Claude Code CLI on the same project.
+
+## Telemetry
+
+Subagent telemetry is recorded via the `SubagentStop` hook (not configured by default — opt-in). The flow:
+
+```
+agent ends → SubagentStop hook → subagent-telemetry.sh
+                               → telemetry-writer.js
+                               → dashboard/data/telemetry.json
+                               → dashboard renders metrics at /telemetry
+```
+
+Captured metrics: agent name, model used, tokens in/out, duration, success/failure, tool calls made. Useful to understand cost per feature and identify agents that are taking too long.
+
+## Design principles
+
+1. **Two layers, no more**. Skill (entry) + Agent (executor). End of story. Adding a third layer requires an ADR approved by `tech-lead`.
+2. **Specific skill wins over catch-all**. If `run-sprint` matched, `project-manager` does not run.
+3. **Hooks are for policy, not logic**. Hooks block dangerous actions, format code, inject memory. Business logic lives in agents.
+4. **Each agent declares its model**. Opus is expensive and rare. Sonnet is the default. Haiku for mechanical work.
+5. **Everything is a file on disk**. `.claude/` is versioned. Harness changes are commits.
+
+## Cross-references
+
+- [Agents reference](agents-reference) — full catalog of the 22 agents + responsibilities + model
+- [Skills reference](skills-reference) — catalog of skills + triggers + outputs
+- [Hooks reference](hooks-reference) — scripts in `scripts/hooks/` + matchers + behavior
+- [Honcho memory](honcho-memory) — architecture of persistent cross-session memory
+- [Autonomy matrix](autonomy-matrix) — who decides what, when to escalate
+- [Pipeline](pipeline) — canonical pipeline from discovery to delivery
+- [Quality gate](quality-gate) — non-negotiable senior+ thresholds
+- [Stack rules](stack-rules) — mandatory versions and conventions
+- [Git Flow](git-flow) — branch model and PRs
+- [Troubleshooting](troubleshooting) — common issues and fixes

package/dashboard/public/content/docs/autonomy-matrix.en.md

@@ -0,0 +1,186 @@
+# Autonomy Matrix
+
+The autonomy matrix is the **master rule** governing how the harness behaves. It defines who decides what and eliminates unnecessary interruptions of the human.
+
+## Fundamental principle
+
+> **Non-negotiable**: agents decide on their own. Asking the human = rare exception. No "I wonder if the user wants X or Y" — the responsible agent **decides and proceeds**.
+
+This principle exists because interrupting the human on every technical decision destroys the productivity the harness was built to deliver. If a `backend-developer` stops on every choice between `@Transactional(REQUIRED)` vs `@Transactional(REQUIRES_NEW)`, the flow dies. The decision is technical, lives inside the agent, and the agent decides.
+
+When the agent really lacks information, it **does not ask** — it picks the most defensible option given available context, documents the choice in an ADR (if macro) or comment (if tactical), and moves on.
+
+## Full table — who decides what
+
+| Domain | Agent | Behavior |
+|---|---|---|
+| Product, scope, rule, UX, flow, priority, MVP, persona, API contract | `product-owner` | **Decides alone.** |
+| Stack, pattern, refactor, lib, tool, debt, organization, final review | `tech-lead` | **Decides alone.** Approves/blocks merges. |
+| Macro architecture, bounded context, integration | `architect` → `tech-lead` | Architect proposes, TL decides. |
+| DB schema, index, migration, performance | `database-engineer` → `tech-lead` (if cross-cutting) | DB engineer decides; TL approves if it affects >1 context. |
+| Security, vuln, OWASP, LGPD | `security-engineer` | **Technical veto** on high/critical — blocks merge without human. |
+| Infra, cost, deploy, CI/CD | `devops-engineer` → `tech-lead` (if > R$ 200/month) | DevOps decides, except for relevant cost. |
+| UI, microinteraction, tokens, a11y | `ux-designer` → `product-owner` (flow/scope) | UX decides "how visual", PO decides "what". |
+| Implementation | `backend-developer` / `frontend-developer` / `mobile-developer` | Implement what TL defined. Product question → PO. Technical question → TL. **Do not escalate to human.** |
+| Tests, coverage, gate | `gate-keeper` | Blocks if senior+ gate fails. Returns to developer. |
+| Triage between agents | `tech-lead` | Conflict between developers → TL. Conflict TL × PO → joint negotiation. |
+
+### Why this structure?
+
+The table is built around two authority poles:
+
+- **`product-owner`** — supreme product authority. Decides everything that is "what" (scope, rule, priority).
+- **`tech-lead`** — supreme technical authority. Decides everything that is "how" (stack, pattern, organization).
+
+Everything else fits below these two poles:
+
+```
+                    ┌─────────────┐         ┌─────────────┐
+                    │product-owner│ ◄────►  │ tech-lead   │
+                    │   (Opus)    │ negotiates │  (Opus)  │
+                    └──────┬──────┘         └──────┬──────┘
+                           │                        │
+              ┌────────────┴──────┐    ┌────────────┼─────────────┐
+              │                   │    │            │             │
+              ▼                   ▼    ▼            ▼             ▼
+        ux-designer        architect      database-       devops-      security-
+       (Sonnet)            (Sonnet)       engineer        engineer     engineer
+                                          (Sonnet)        (Sonnet)     (Opus, veto)
+              │                  │              │             │            │
+              └──────────┬───────┴──────────────┴─────────────┴────────────┘
+                         ▼
+                  backend-developer / frontend-developer / mobile-developer
+                                       (Sonnet)
+                         │
+                         ▼
+                  qa-engineer ◄─── gate-keeper (Sonnet, blocks)
+                  (Sonnet)
+```
+
+## When to escalate to the human (and ONLY when)
+
+### `product-owner` escalates ONLY in 4 situations:
+
+1. **Irreversible action on real customer data** — delete/overwrite with no recovery, drop table in prod, LGPD purge without backup.
+2. **Relevant financial cost** — sign a paid SaaS, change cloud tier, hire a service that becomes recurring OpEx.
+3. **Breaking change on a PUBLIC contract already published** — v1 endpoint with external clients consuming, schema change on a published event.
+4. **Identity/brand change approved by another area** — change product name, logo, public URL.
+
+### `tech-lead` escalates ONLY in 3 situations:
+
+1. **Technical requirement conflict not resolvable with grounding** — PO requests X but the current stack cannot support X at all without rewrite.
+2. **Breaking change on a production public contract** — coordinate maintenance window with external client.
+3. **Infra cost > R$ 200/month additional** — provision new managed instance, scale DB tier, hire paid CDN.
+
+### `security-engineer` escalates ONLY in:
+
+- **Irreversible PII purge** — when it finds a leak and needs to wipe real customer data with no undo.
+
+For everything else (high/critical vuln, OWASP Top 10, missing security header, vulnerable dependency), `security-engineer` **technically vetoes** the merge without needing the human.
+
+### Specialists NEVER escalate to the human
+
+The 17 specialist agents (analyst, architect, backend-developer, frontend-developer, mobile-developer, database-engineer, devops-engineer, qa-engineer, code-reviewer, ux-designer, n8n-specialist, sprint-runner, scaffold, release-engineer, migrator, auditor, brain-keeper) **DO NOT escalate to human**.
+
+The rule is:
+- **Product** doubt → escalate to `product-owner`.
+- **Technical** doubt → escalate to `tech-lead`.
+- Each decides within its domain without consulting anyone else.
+
+## Form of escalation (when justified)
+
+When PO or TL needs to escalate (in the 4+3 cases above), the rule is **non-negotiable**:
+
+> Never an open question. Always **proposal + recommendation + impact of the opposite decision**.
+
+### Correct example
+
+> "Provision managed Redis Cluster (+R$ 380/month) to support 10x traffic in 6 months. I recommend approving now; if we keep single-node, cache queues in 2 months and p95 climbs to 800ms."
+
+This form:
+- Presents a concrete proposal (managed Redis Cluster).
+- Has numeric cost (+R$ 380/month).
+- Has explicit recommendation (approve now).
+- Has impact of the opposite decision (queue + p95 800ms in 2 months).
+
+The human reads this in 10 seconds and decides. No back and forth.
+
+### Wrong example
+
+> "Should we use Redis Cluster or stay on single-node?"
+
+This form is **forbidden**. No proposal, no recommendation, no impact. It transfers the technical decision back to the human without grounding. `tech-lead` must reformulate before escalating.
+
+## Anti-pattern "asking the human"
+
+The examples below show up frequently in miscalibrated agents. In all of them, the correct form is the agent deciding and moving on.
+
+### Anti-pattern 1 — Trivial technical choice
+
+| Wrong | Correct |
+|---|---|
+| "Do you prefer `UUID v4` or `UUID v7` for the PK?" | Agent picks `UUID v7` (Postgres 17 default + natural temporal ordering). Moves on. If relevant, documents in an ADR. |
+| "Should I use `@Transactional` or `@Transactional(readOnly=true)` on this service?" | Agent analyzes: has writes? `@Transactional`. Read-only? `@Transactional(readOnly=true)`. Decides. |
+
+### Anti-pattern 2 — Implementation choice
+
+| Wrong | Correct |
+|---|---|
+| "Can I create POST /products or do you prefer PUT?" | Signup = POST (standard REST). Agent decides. |
+| "Should I use `RestClient` or `WebClient` for this HTTP client?" | TL already decided (CLAUDE.md): `RestClient` for sync, `WebClient` for reactive. Agent reads and follows. |
+
+### Anti-pattern 3 — UX choice
+
+| Wrong | Correct |
+|---|---|
+| "Modal or drawer for the edit form?" | `ux-designer` consults design tokens + current project pattern, picks one, moves on. No pattern? Modal (more conservative). |
+| "Primary button blue or green?" | `ux-designer` uses the color tokens already defined in the project. No token? Creates one following the ng-bootstrap pattern. |
+
+### Anti-pattern 4 — Test choice
+
+| Wrong | Correct |
+|---|---|
+| "Should I write unit or integration tests for this service?" | Senior+ gate requires line coverage >= 85% + branches >= 80%. Agent writes whatever is needed to hit the threshold, prioritizes unit (pyramid), adds integration where the service crosses a boundary. |
+| "Should I skip the a11y test on this component?" | NEVER. A11y serious/critical = 0. No exception. Agent writes the test. |
+
+## Conflicts between agents
+
+The matrix does not by itself resolve conflicts that cross domains. For that there are three protocols:
+
+### Specialist × specialist conflict
+
+Example: `backend-developer` wants to expose `OffsetDateTime`, `frontend-developer` wants `Instant`. They disagree on the API contract.
+
+**Protocol**: `tech-lead` triages. Since API contract is technical, TL decides and both follow. If TL determines it affects product (user-visible change in timezone), TL takes it to `product-owner` for validation.
+
+### Specialist × `tech-lead` conflict
+
+Example: `database-engineer` wants hash partitioning, `tech-lead` imposes range. DB engineer thinks it will perform worse in production.
+
+**Protocol**: TL is the technical authority. DB engineer presents the analysis as **proposal + recommendation + opposite impact**. If TL still maintains the decision, it ends. If DB engineer demonstrates via benchmark that the decision has critical impact (e.g. hot partition in 2 weeks), TL reconsiders — no wounded ego, no falling back to the human.
+
+### `tech-lead` × `product-owner` conflict
+
+Example: PO wants feature X in 1 sprint, TL says the auth layer needs a refactor first — 2 additional sprints.
+
+**Protocol**: joint negotiation. PO and TL exchange **proposals + impacts**:
+- PO: "feature X now, refactor later — clients have been asking for 3 months."
+- TL: "feature X without refactor implies role leakage between tenants — LGPD risk."
+- They negotiate until they reach: minimum refactor in the current sprint (role auth only) + feature X in parallel.
+
+If they cannot agree, **PO has final say on scope, TL has final say on technical**. If conflict persists, they jointly escalate to human as a governance item (rare).
+
+## Executive summary
+
+- Agents decide on their own. Default = decision.
+- Human is only interrupted in 4 (PO) + 3 (TL) + 1 (security) absolute cases.
+- Specialists never escalate to human — they escalate to PO or TL.
+- Every escalation has a fixed form: proposal + recommendation + impact.
+- Conflicts between agents resolve by TL triage, with PO as product arbiter.
+
+## Cross-references
+
+- [Agents reference](agents-reference) — full list of the 22 agents + model + responsibilities
+- [Pipeline](pipeline) — where and how each agent shows up in the end-to-end flow
+- [Quality gate](quality-gate) — thresholds that `gate-keeper` and `security-engineer` enforce without human
+- [Architecture overview](architecture-overview) — 2-layer macro model