@event4u/agent-config 1.15.0 → 1.17.0

package/.agent-src/rules/commit-conventions.md

@@ -7,13 +7,15 @@ source: package
 
 # Commit Conventions
 
-All commit messages and squash/merge titles follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+All commit messages and squash/merge titles must follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
 
 ## Format
 
 - With scope: `<type>(<scope>): <description>`
-- Without scope: `<type>: <description>`
-- Always English. Imperative mood. Max 72 chars first line.
+- Without scope: `<type>: <description>` (omit parentheses when no scope)
+- **Always English** — regardless of user's language.
+- **Imperative mood** ("add feature", not "added feature").
+- **First line max 72 characters.**
 
 ## Types
 
@@ -21,24 +23,24 @@ All commit messages and squash/merge titles follow [Conventional Commits](https:
 |---|---|
 | `feat` | New user-facing functionality |
 | `fix` | Bug fix |
-| `refactor` | Structure change, no behavior change |
+| `refactor` | Code/structure change, no behavior change |
 | `docs` | Documentation only |
 | `test` | Tests only |
-| `chore` | Maintenance, deps, cleanup |
-| `ci` | CI/CD, workflows |
-| `style` | Formatting only |
+| `chore` | Maintenance (deps, configs, tooling, cleanup) |
+| `ci` | CI/CD and workflow changes |
+| `style` | Code style (formatting, no logic change) |
 | `perf` | Performance improvement |
-| `build` | Build tooling, packaging |
+| `build` | Build tooling / packaging changes |
 
 ## Scope
 
-- Jira ticket ID when branch has one: `DEV-1234`
-- Otherwise short area name: `api`, `auth`, `skills`
-- Optional — only add when it improves clarity.
+- Use the **Jira ticket ID** as scope when the branch contains one (e.g. `DEV-1234`).
+- Otherwise use a short module or area name (e.g. `api`, `auth`, `skills`).
+- Scope is optional — only add when it improves clarity.
 
 ## Breaking changes
 
-Mark with `!` or `BREAKING CHANGE:` footer:
+Mark explicitly with `!` after type/scope or `BREAKING CHANGE:` in footer:
 
 ```
 feat(api)!: rename invoice status values
@@ -47,7 +49,8 @@ refactor(auth)!: remove legacy session flow
 
 ## Commit splitting
 
-Mixed concerns → split into multiple commits. Don't hide unrelated changes in one.
+If a change mixes unrelated concerns, split into multiple commits.
+Do NOT hide bug fixes, CI work, docs, and refactors in one commit.
 
 ## Examples
 
@@ -61,4 +64,4 @@ ci(lint): add skill-lint workflow
 docs(roadmap): add phase 3 implementation plan
 ```
 
-→ Type selection rules, anti-patterns, decision checklist: `guidelines/php/git.md`
+→ Full type selection rules and anti-patterns: see guideline `docs/guidelines/php/git.md`.

package/.agent-src/rules/commit-policy.md

@@ -3,6 +3,8 @@ type: "always"
 description: "Commit policy — never commit and never ask about committing unless the user said so this turn, the roadmap authorizes it, or a commit command is invoked"
 alwaysApply: true
 source: package
+load_context:
+  - .agent-src.uncompressed/contexts/authority/commit-mechanics.md
 ---
 
 # Commit Policy
@@ -36,26 +38,12 @@ Exactly four ways the agent may commit:
 3. **Commit command invoked** — `/commit` (with confirmation) or
    `/commit-in-chunks` (auto-split, no confirmation).
 4. **Roadmap authorization** — the roadmap file lists explicit commit
-   steps and the user invoked roadmap execution. See
-   [Roadmap-authorized commits](#roadmap-authorized-commits) below.
+   steps and the user invoked roadmap execution.
 
-Anything else → no commit.
-
-## Hard Floor still applies — bulk deletions and infra changes
-
-Even when one of the four exceptions above authorizes a commit, the
-[`non-destructive-by-default`](non-destructive-by-default.md) Hard
-Floor still fires when the diff:
-
-- Removes a directory
-- Deletes ≥5 unrelated files
-- Touches Terraform / Pulumi / k8s manifests / Ansible / cloud-config
-
-In those cases, **surface the diff** (paths + counts) and confirm
-this turn before committing — even under `/commit-in-chunks`,
-roadmap pre-scan authorization, or an explicit "commit this now". The
-four exceptions cover *whether* commits happen; the Hard Floor covers
-*which diffs* still need a separate confirmation.
+Anything else → no commit. Hard Floor (bulk deletions, infra changes)
+still fires on top of any exception — see
+[`commit-mechanics`](../contexts/authority/commit-mechanics.md) for
+the diff triggers and the roadmap-authorized commit flow.
 
 ## NEVER ask about committing
 
@@ -64,10 +52,10 @@ variant is **forbidden**. The user invokes a command or says so
 explicitly. Don't surface a commit option in numbered-options blocks
 unless the rest of the message would be incomplete without it.
 
-The same speech-act check from [`autonomous-execution`](autonomous-execution.md#speech-act-check--the-phrase-must-be-a-meta-instruction-to-the-agent)
-applies in reverse: an explicit commit phrase inside a quote, code
-block, or content (e.g. a copy-paste of a chat log) is **not** a
-permission grant.
+Quoted commit phrases (chat-log paste, log excerpt, roadmap snippet)
+are **not** permission — see
+[`commit-mechanics`](../contexts/authority/commit-mechanics.md)
+§ Speech-act check.
 
 ## NEVER write commit steps into roadmaps unsolicited
 
@@ -79,29 +67,13 @@ delivery decision; roadmaps plan **work**.
 If the user explicitly wants commit steps in the roadmap, write them
 clearly and unambiguously (e.g. "Commit phase X: chore: …").
 
-## Roadmap-authorized commits
-
-When **executing** a roadmap that contains commit steps:
-
-- **Non-autonomous mode** (`personal.autonomy: off`, or `auto`
-  before opt-in) — agent may ask before each commit step. The user
-  authorized commits by writing them into the roadmap, but retains
-  step-level control.
-- **Autonomous mode** (`personal.autonomy: on`, or `auto` after
-  opt-in) — agent does a quick pre-scan of the roadmap **before
-  starting execution**. If commit steps are found, ask **once** at
-  the very start: "Roadmap contains N commit steps — should they be
-  executed?". After that, honor or skip per the answer.
-  No re-asking per step.
-
-The pre-scan ask is the **only** permitted commit-related question
-in autonomous mode. Once answered, the decision is cached for the
-rest of the roadmap execution.
-
 ## See also
 
 - [`autonomous-execution`](autonomous-execution.md) — when to suppress
   trivial questions; this rule survives the suppression.
+- [`no-cheap-questions`](no-cheap-questions.md) — commit asks are
+  cheap by construction; this rule is the canonical Iron Law, the
+  cheap-questions rule cites it and refuses to surface the option.
 - [`scope-control`](scope-control.md) — git-ops permission gate
   (push, merge, branch, PR, tag stay separately permission-gated).
 - [`/commit`](../commands/commit.md) — split and commit with confirmation.

package/.agent-src/rules/context-hygiene.md

@@ -1,7 +1,7 @@
 ---
-type: "always"
-alwaysApply: true
-description: "3-failure rule for debugging and fixing errors — stop after 3 consecutive failed attempts, dump state, and recommend a fresh session"
+type: "auto"
+alwaysApply: false
+description: "When debugging, fixing errors, or running long conversations — 3-failure stop rule, tool-loop detection, fresh-chat triggers"
 source: package
 ---
 

package/.agent-src/rules/direct-answers.md

@@ -1,6 +1,6 @@
 ---
 type: "always"
-description: "Always — direct, unembellished answers. No flattery, no invented facts (verify the load-bearing ones with tools, otherwise ask). Emojis only as functional markers — status, warning, mandated. Brevity is the default."
+description: "Always — direct, unembellished answers. No flattery, no invented facts (verify load-bearing claims, otherwise ask). Emojis only as functional markers. Brevity is the default."
 alwaysApply: true
 source: package
 ---
@@ -18,18 +18,12 @@ NEVER PRAISE THE USER'S IDEA TO MAKE THEM HAPPY.
 ANSWER THE SUBSTANCE. SHIP THE TRUTH.
 ```
 
-- No positive adjectives about the user, their question, idea, or
-  work product as an opener.
-- No subjective judgments on the user's code, decisions, or work
-  products ("nice approach", "clean design", "boring") unless the
-  user asked for an evaluation.
-- "Good catch" / "you're right" only when literally true and
-  load-bearing for the answer.
-- Acknowledge mistakes without performative apologies. One sentence,
-  switch behavior.
+- No positive adjectives about user, question, idea, or work product as opener.
+- No subjective judgments on user's code/decisions ("nice approach", "boring") unless evaluation was asked.
+- "Good catch" / "you're right" only when literally true and load-bearing.
+- Acknowledge mistakes without performative apologies — one sentence, switch behavior.
 
-Failure mode: praise as a hedge before delivering bad news. Drop the
-cushion, deliver the news.
+Failure mode: praise as a hedge before bad news. Drop the cushion, deliver the news.
 
 ## Iron Law 2 — No Invented Facts (severity-tiered)
 
@@ -39,19 +33,18 @@ THE MORE LOAD-BEARING THE CLAIM, THE HARDER YOU VERIFY.
 WHEN VERIFICATION IS NOT WORTH THE COST → ASK.
 ```
 
-| Severity | Examples | Required action |
-|---|---|---|
-| **High — load-bearing** | File paths, function/method signatures, version numbers, security claims, API contracts, "this test passes/fails", "this method exists" | MUST verify with tools (`view`, `grep`, `codebase-retrieval`, command output) before claiming. If too expensive → ask the user. |
-| **Medium — project-shape** | "This project uses X for Y", general conventions, file location guesses | Verify if one tool call reaches it; otherwise hedge explicitly ("I'd guess X — not checked"). |
-| **Low — well-known idioms** | Generic language/framework idioms, illustrative examples, well-documented public APIs | Inference acceptable. Mark as inference if not 100% sure. |
+| Severity | Required action |
+|---|---|
+| **High — load-bearing** (file paths, signatures, version numbers, security claims, "this test passes") | MUST verify with `view`, `grep`, `codebase-retrieval`, or fresh command output. Too expensive → ask. |
+| **Medium — project-shape** ("uses X for Y", conventions, file location) | Verify if one tool call reaches it; otherwise hedge: *"I'd guess X — not checked"*. |
+| **Low — well-known idioms** (generic language/framework idioms, public APIs) | Inference acceptable. Mark as inference if not 100% sure. |
+
+Concrete examples and hedge-language patterns:
+[`asking-and-brevity-examples`](../../docs/guidelines/agent-infra/asking-and-brevity-examples.md#direct-answers--severity-tiered-claim-examples).
 
 User override: "just guess", "rough estimate is fine", "skip the
 verify" → drop to Low for that turn.
 
-Hedging language is explicit and short: "haven't verified X",
-"guess, not checked". Never bare "probably" / "vermutlich" without
-naming what's unverified.
-
 ## Iron Law 3 — Brevity by Default
 
 ```
@@ -60,45 +53,37 @@ LONG ANSWERS ARE A FAILURE MODE, NOT A SIGN OF EFFORT.
 ```
 
 - Skip restating the user's question.
-- Skip announcing intent ("Let me…", "I will now…"). Just do.
-- Skip explaining why a tool was used — the call result speaks.
-- Skip post-hoc summary unless the user must recheck a decision.
-- Multi-step work → bullet points, not paragraphs.
-- Question with one true answer → one sentence + the answer.
-
-`token-efficiency` covers the loop side (no repeated tool calls);
-this rule covers the per-reply-length side. **Never overrides**
-`user-interaction` (numbered options stay) or command-mandated
-steps — brevity ≠ skipping required questions.
+- Skip announcing intent ("Let me…", "I will now…") — just do.
+- Skip explaining tool use — the call result speaks.
+- Skip post-hoc summary unless rechecking a decision.
+- Multi-step → bullets, not paragraphs.
+- One-true-answer question → one sentence + the answer.
 
-## Emoji Scope — Whitelist + Blacklist
+`token-efficiency` covers the loop side; this rule covers per-reply
+length. **Never overrides** `user-interaction` (numbered options
+stay) or command-mandated steps.
 
-Emojis are **functional markers**, never decoration.
+## Emoji Scope — functional markers only
 
-**Whitelist — allowed and expected:**
+**Whitelist (allowed):**
 
-- Mandated markers from rules/scripts: `📒` (chat-history heartbeat,
-  verbatim per `chat-history-visibility`), mode markers from
-  `role-mode-adherence`.
-- CLI status icons: `❌`, `✅`, `⚠️` — two-space rule from
-  `language-and-tone` § other-language-rules still applies.
-- Roadmap status checkboxes: `[x]`, `[~]`, `[-]`.
+- Mandated markers: `📒` (chat-history heartbeat, verbatim per
+  `chat-history-visibility`), mode markers from `role-mode-adherence`.
+- CLI status: `❌`, `✅`, `⚠️` (two-space rule from `language-and-tone`).
+- Roadmap checkboxes: `[x]`, `[~]`, `[-]`.
 
-**Blacklist — never in the agent's own prose:**
+**Blacklist (never in prose):**
 
 - Opening flair: ✨, 🚀, 🎉, 💡, 🔥, 👍.
-- Empathy signaling: ❤️, 🤗, 😊.
-- Section dividers / headline ornaments.
-- Reaction reactions to the user's message.
+- Empathy: ❤️, 🤗, 😊.
+- Section dividers, headline ornaments, reaction emojis.
 
-If unsure whether a given emoji is functional → assume blacklist.
+Unsure → assume blacklist.
 
 ## Failure modes the user will call out
 
-- "Great question, …" / "Das ist eine gute Frage" — Iron Law 1.
-- Stating a function name without `grep`/`view` — Iron Law 2.
-- Three paragraphs for a one-line answer — Iron Law 3.
-- ✨/🎉/💡 to mark "this is interesting" — emoji blacklist.
+Trigger phrases per Iron Law and the in-language correction pattern:
+[`asking-and-brevity-examples`](../../docs/guidelines/agent-infra/asking-and-brevity-examples.md#direct-answers--failure-modes-the-user-will-call-out).
 
 When called out: acknowledge once in the user's language, switch,
 no excuses (mirrors `language-and-tone` § slip handling).

package/.agent-src/rules/docker-commands.md

@@ -44,10 +44,10 @@ docker compose exec -T <php-service> vendor/bin/phpunit
 
 ## Build / Task Runner
 
-Before using raw `docker compose exec`, check if the consumer project
-ships a `Makefile` — it often wraps common ops (`make console`,
-`make test`, `make phpstan`). Read the Makefile first. If the project
-uses another task runner, inspect its config before falling back to
-raw `docker compose exec`.
+Before using raw `docker compose exec` commands, check if the consumer
+project ships a `Makefile` for common targets (e.g. `make console`,
+`make test`, `make phpstan`). Read the Makefile first to discover
+available shortcuts. If the project uses a different task runner,
+inspect its config file before defaulting to raw `docker compose exec`.
 
 Frontend commands (npm, webpack) run on the host or in the node container.

package/.agent-src/rules/docs-sync.md

@@ -2,6 +2,8 @@
 type: "auto"
 description: "Keeping .augment/ contexts, counts, and cross-references in sync when creating, renaming, or deleting skills, commands, rules, guidelines, templates, or any agent infrastructure files"
 source: package
+load_context:
+  - .agent-src.uncompressed/contexts/communication/rules-auto/docs-sync-mechanics.md
 ---
 
 # Docs Sync
@@ -18,33 +20,16 @@ A new rule/skill/command without its index entry, count update, and context upda
 1. Create/delete the file
 2. **Immediately** update `contexts/augment-infrastructure.md` (counts + category tables)
 3. Check cross-references in contexts and routing hints (inline "see X skill" references)
+4. If a **skill** was added/renamed/deleted: update distribution manifests
+5. If a **hook** was added/renamed/deleted: update hook registries
+6. If **content** changed: run the consistency grep across other artefacts
 
-Steps 2–3 are NOT optional. Do NOT present the result to the user until all steps are done.
+Steps 2–6 are NOT optional. Do NOT present the result to the user until all steps are done.
 
 **Two modes:**
-- **Reactive** (automatic): Triggered by add/remove/rename or scope/description/count changes → sync counts, contexts, cross-references.
+- **Reactive** (automatic): Triggered by add/remove/rename or scope/description/count changes → sync counts, contexts, cross-references, manifests, registries.
 - **Proactive** (on demand): Full audit → find duplicates, thin skills, redundancy, stale content → fix or merge. Ask before destructive actions.
 
-## What to update
-
-When a file is **added, removed, or renamed**:
-
-| Change | Files to update |
-|---|---|
-| Skill/command/rule count changes | `contexts/augment-infrastructure.md` (count + category table) |
-| New skill category | `contexts/augment-infrastructure.md` + `contexts/skills-and-commands.md` |
-| New workflow chain | `contexts/skills-and-commands.md` (workflow chains section) |
-
-## Cross-reference updates
-
-When a skill is **added or its scope changes**, check and update:
-
-| What | Where to check |
-|---|---|
-| Inline routing hints | "see X skill" or "use X instead" references in other skills |
-| Guideline cross-references | Guidelines that reference the changed skill |
-| Command skill references | Commands that use the changed skill |
-
 ## Settings template sync
 
 When a skill, rule, or command **reads a new setting** from `.agent-settings.yml` that does not yet
@@ -55,60 +40,21 @@ exist in `.augment/templates/agent-settings.md`:
 3. **Add a comment** above the key explaining what it does.
 4. **Update the local `.agent-settings.yml`** — add the new key with its default value.
    Preserve all existing values, apply template order and comments. Follow the
-   [section-aware merge rules](../guidelines/agent-infra/layered-settings.md#section-aware-merge-rules)
+   [section-aware merge rules](../../docs/guidelines/agent-infra/layered-settings.md#section-aware-merge-rules)
    so the user benefits immediately without running a separate command.
 
 **This step is mandatory.** If the template gains a new key but the local `.agent-settings.yml`
 is not updated, the user cannot discover the new setting exists.
 
-## Distribution manifests and hook registries
-
-`.augment/`-internal sync (counts, contexts, cross-refs) is one half. The
-other half is **distribution manifests** that ship the package to consumers
-and **hook registries** that wire engine code into platform lifecycles.
-These are not auto-derived — they drift silently until CI catches them, and
-on cooperative platforms (no pre-commit) they can sit broken in a branch
-for hours.
-
-When a **skill** is added, renamed, or deleted under
-`.agent-src.uncompressed/skills/`:
-
-| Manifest | Required update |
-|---|---|
-| `.claude-plugin/marketplace.json` | Add/remove the `./.claude/skills/<name>` entry in `plugins[0].skills[]`, alphabetical position. Caught by `scripts/lint_marketplace.py` in CI. |
-| `.augment-plugin/marketplace.json` | Skill-name-agnostic — no update needed. Touch only when plugin metadata (description, tags) changes. |
-| `.github/plugin/marketplace.json` | Same as above — metadata-only manifest. |
-
-When a **hook** is added, renamed, or deleted under
-`.agent-src.uncompressed/templates/scripts/work_engine/hooks/builtin/`:
-
-| Registry | Required update |
-|---|---|
-| `templates/scripts/work_engine/hooks/builtin/__init__.py` | New hook class → add the import + `__all__` entry. Single source of truth for engine-side registration. |
-| `templates/consumer-settings/claude-settings.json` | Only when a **new platform event** is wired (e.g. first time a hook listens on `SessionEnd`). Existing hooks reuse the `./agent-config chat-history:hook --platform claude` dispatcher — no per-hook entry needed. |
-| `templates/consumer-settings/augment-cli-hooks.json` | Same logic — new platform event → new `command` block; new hook on existing event → no update. |
-
-Failure mode that motivated this section: a skill on disk without its
-`marketplace.json` entry passes local edits, builds, and tests — only
-CI catches it via `lint_marketplace`. The cooperative path is
-"agent updates the manifest in the same response as the skill"; the
-structural backstop is a pre-commit hook installed by
-`scripts/install-hooks.sh` that runs `lint_marketplace` on every
-commit. Run the installer once per clone; bypass for an unrelated WIP
-commit is `git commit --no-verify`.
-
-## Content consistency
-
-**CRITICAL — MANDATORY CHECK:** When a rule, skill, or guideline's **content** is changed
-(not just metadata), you MUST search for **all other rules, skills, and guidelines that cover
-the same topic** and verify they are consistent.
-
-```bash
-grep -rl "TOPIC" .augment/rules/ .augment/skills/ .augment/guidelines/ --include="*.md"
-```
+## Lookup tables and details — see mechanics
 
-If any file contradicts or is missing the updated information → **update it in the same response**.
-Inconsistent documentation is worse than no documentation.
+The exact "what to update" tables, cross-reference targets,
+distribution-manifest update tables (`marketplace.json` etc.), hook
+registry update tables (`__init__.py`, consumer-settings JSON), the
+failure mode that motivated the manifest section, and the content
+consistency `grep` snippet all live in
+[`contexts/communication/rules-auto/docs-sync-mechanics.md`](../contexts/communication/rules-auto/docs-sync-mechanics.md).
+Pull it whenever a sync trigger fires.
 
 ## Do NOT
 

package/.agent-src/rules/e2e-testing.md

@@ -9,7 +9,7 @@ source: package
 
 ## Before writing E2E tests
 
-1. **Read the guideline** — `.augment/guidelines/e2e/playwright.md` for all conventions and patterns.
+1. **Read the guideline** — `../../docs/guidelines/e2e/playwright.md` for all conventions and patterns.
 2. **Check existing tests** — match the project's structure, fixtures, and Page Object patterns.
 3. **Check `playwright.config.ts`** — base URL, browsers, timeouts, projects.
 

package/.agent-src/rules/guidelines.md

@@ -12,7 +12,7 @@ Coding guidelines live in `.augment/guidelines/` organized by language.
 
 ## Available Guidelines
 
-### PHP (`.augment/guidelines/php/`)
+### PHP (`../../docs/guidelines/php/`)
 
 | File | Topic |
 |---|---|
@@ -37,7 +37,7 @@ Coding guidelines live in `.augment/guidelines/` organized by language.
 | `websocket.md` | WebSocket conventions — Broadcasting, channel types, connection management |
 | `patterns.md` | Design patterns index (links to `patterns/` subdirectory) |
 
-### PHP Patterns (`.augment/guidelines/php/patterns/`)
+### PHP Patterns (`../../docs/guidelines/php/patterns/`)
 
 | File | Pattern |
 |---|---|
@@ -51,11 +51,11 @@ Coding guidelines live in `.augment/guidelines/` organized by language.
 | `pipelines.md` | Laravel Pipeline pattern |
 | `strategy.md` | Strategy pattern implementation |
 
-### E2E (`.augment/guidelines/e2e/`)
+### E2E (`../../docs/guidelines/e2e/`)
 
 Playwright best practices, Page Objects, fixtures, CI.
 
-### Agent Infrastructure (`.augment/guidelines/agent-infra/`)
+### Agent Infrastructure (`../../docs/guidelines/agent-infra/`)
 
 | File | Topic |
 |---|---|

package/.agent-src/rules/improve-before-implement.md

@@ -41,10 +41,10 @@ Before coding, quickly verify:
 - Does it follow established patterns in the codebase?
 - Does it contradict existing conventions?
 - Do **multiple valid patterns/frameworks** already exist (e.g. Tailwind + Flux, multiple form libraries, competing state stores)? If yes, do NOT pick one arbitrarily — ask which to use.
-- Is the change a **second branch on the same discriminator** — second `match`/`switch` arm, second `if/elseif`, or second class hardcoded to one enum value (e.g. `Provider::FOO`, `'stripe'`)? If yes, run the Strategy sniff test before adding the branch — see [`guidelines/php/patterns/strategy.md`](../guidelines/php/patterns/strategy.md#sniff-test--when-an-enumstring-discriminator-wants-to-become-a-strategy).
+- Is the change a **second branch on the same discriminator** — second `match`/`switch` arm, second `if/elseif`, or second class hardcoded to one enum value (e.g. `Provider::FOO`, `'stripe'`)? If yes, run the Strategy sniff test before adding the branch — see [`docs/guidelines/php/patterns/strategy.md`](../../docs/guidelines/php/patterns/strategy.md#sniff-test--when-an-enumstring-discriminator-wants-to-become-a-strategy).
 
 **If misfit** → show evidence (file references), propose alternative.
-**If multiple valid options** → list them, ask which to use. See [`no blind implementation`](../guidelines/agent-infra/agent-interaction-and-decision-quality.md#2-no-blind-implementation).
+**If multiple valid options** → list them, ask which to use. See [`no blind implementation`](../../docs/guidelines/agent-infra/agent-interaction-and-decision-quality.md#2-no-blind-implementation).
 
 ### 3. Is the approach sound?