@event4u/agent-config 5.10.1 → 6.1.0

package/.agent-src/skills/threat-modeling/SKILL.md

@@ -1,197 +0,0 @@
----
-model_tier: high
-name: threat-modeling
-description: "Use when adding auth, webhooks, uploads, queues, secrets, tenant boundaries, or public endpoints — produces trust boundaries + abuse cases mapped to files, BEFORE implementation."
-personas:
-  - security-engineer
-domain: quality
-council_depth: deep
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# threat-modeling
-
-> You are a reviewer specialized in **pre-impl threat analysis**.
-> Your only job is to produce a compact threat model for a planned change —
-> actors, assets, trust boundaries, abuse cases, and the minimum controls
-> the implementer must add. You do **not** audit existing code end-to-end,
-> you do **not** review diffs, you do **not** implement controls — sibling
-> skills handle those.
-
-## When to use
-
-* The change adds or modifies authentication, authorization, or permission checks
-* The change adds a public endpoint, webhook, file upload, queue worker,
-  scheduled task, or third-party integration
-* The change touches sensitive data, tenant boundaries, secrets, billing flows,
-  or admin-only capabilities
-* A `security-sensitive-stop-rule` trigger fired and the agent must produce a
-  risk review before patching
-
-Do NOT use when:
-
-* The change is a cosmetic refactor or documentation-only edit — skip entirely
-* The change is a diff ready for review — route to
-  [`judge-security-auditor`](../judge-security-auditor/SKILL.md)
-* The concern is a full-codebase security posture review — route to
-  [`security-audit`](../security-audit/SKILL.md)
-* The concern is end-to-end authorization enforcement — route to
-  [`authz-review`](../authz-review/SKILL.md)
-* The concern is output/log leakage on an existing API — route to
-  [`data-exposure-review`](../data-exposure-review/SKILL.md)
-* The concern is implementing the controls once identified — route to
-  [`security`](../security/SKILL.md)
-
-## Procedure
-
-### 1. Anchor on the planned change
-
-Read the task description (ticket, feature plan, spec) and the entrypoints
-the change will touch. You are modelling **the stated change**, not the
-whole system. If the change is unclear from available context, stop and ask
-before continuing — never invent a threat model for an imagined feature.
-
-### 2. Inspect the execution path
-
-Trace the path once through existing code:
-
-- Where does untrusted input enter? (route, webhook, queue payload, CLI arg,
-  uploaded file, imported record)
-- Which actor types cross this path? (anonymous, authenticated user, admin,
-  service account, queue worker, cron)
-- What assets does the path touch? (PII, credentials, internal IDs, billing,
-  tenant-scoped records, files, secrets)
-- Where are the privilege boundaries? (auth gate, authorization layer, tenant
-  scope, admin gate)
-
-### 3. Model the risks
-
-For every distinct abuse case, answer:
-
-| Field | What to fill in |
-|---|---|
-| Entry point | route / job / webhook + concrete file |
-| Actor | who can trigger it |
-| Precondition | what must be true (auth state, data state) |
-| Impact | concrete damage (data loss, privilege escalation, DoS, leakage) |
-| Current control | what exists today |
-| Missing control | what the change must add |
-
-Prioritize by **impact × plausibility**, not by novelty. Skip generic
-OWASP bullets unless you can anchor them in a concrete file or line.
-
-### 4. Convert risks to engineering actions
-
-For each prioritized abuse case, propose the **smallest effective control**
-and name the exact file/layer it belongs in:
-
-- input validation → where
-- authorization check → where
-- rate limiting → where
-- output filtering → where
-- safer default → where
-- logging / alerting → where
-
-State whether a new **negative test** is required and what condition it
-must assert (e.g. *"POST /imports with tenant-B id from tenant-A session
-returns 403"*).
-
-## Validation
-
-Before finalizing the threat model, confirm:
-
-1. Every entry point has at least one identified control owner
-2. Every 🔴 abuse case has either an existing control or a required new one
-3. Every 🔴 abuse case has at least one proposed negative test
-4. You have NOT produced generic advice — every risk cites a file, route, or job
-5. You have NOT proposed offensive testing steps, exploit chains, or bypass ideas
-6. If the change is out of scope for threat modelling (no trust boundary
-   crossed), you have said so explicitly and stopped
-
-## Output format
-
-```
-Skill:   threat-modeling
-Target:  <feature / ticket / change summary>
-
-Actors:   <list, one per line>
-Assets:   <list, one per line>
-Entry points:   <route / job / webhook — file:line>
-Trust boundaries:   <where untrusted → trusted crossings happen>
-
-Abuse cases (prioritized):
-  🔴  <name> — entry point · actor · precondition
-      Impact: <concrete damage>
-      Current control: <what exists>
-      Missing control: <what to add, where>
-      Required test: <negative assertion>
-  🟡  ...
-  🟢  ...
-
-Implementation plan:
-  1. <control>, <file/layer>
-  2. ...
-
-Missing tests:
-  1. <assertion>, <test file>
-```
-
-Severity: 🔴 exploitable by external actor with current or no privilege /
-🟡 exploitable only with elevated privilege or partial auth / 🟢 defense-in-depth
-improvement, not a concrete exploit path.
-
-Required fields (ordered):
-
-1. **Skill** and **Target** — one-line change summary
-2. **Actors**, **Assets**, **Entry points**, **Trust boundaries**
-3. **Abuse cases** — prioritized; every entry cites entry point + actor + impact + current + missing control + required test
-4. **Implementation plan** — ordered controls mapped to files/layers
-5. **Missing tests** — ordered negative assertions
-
-Runtime confirmation (e.g. *"reproduce the abuse against staging"*, *"query
-the DB to confirm scope leakage exists today"*) is a follow-up for the
-implementer — **this skill does not execute tools, reproduce exploits, or
-run tests**.
-
-## Gotcha
-
-* **Generic OWASP bullets without a file anchor** — "SQL injection risk" is
-  noise unless you cite the query. Drop it or anchor it.
-* **Confusing authentication with authorization** — a logged-in user is not an
-  authorized user. Model authorization as a distinct boundary even when auth
-  is already enforced upstream.
-* **Treating queue workers and webhooks as trusted** — they carry attacker-
-  influenced payloads. Model them as untrusted entry points.
-* **Modelling the whole system when the change is narrow** — the model is
-  scoped to the planned change. Out-of-scope risks belong to `security-audit`.
-* **Producing offensive test steps** — you name abuse cases and required
-  controls, not exploit procedures.
-
-## Do NOT
-
-* NEVER produce exploit chains, payloads, or bypass techniques — if the task
-  asks for offensive work, stop and refuse per `never-help-build-offensive-cyber-capability`
-* NEVER return a threat model out of politeness when no trust boundary is crossed — say so and stop
-* NEVER treat "internal" or "behind the WAF" as a substitute for a control
-* NEVER approve a plan without at least one negative test per 🔴 abuse case
-* NEVER silently fall back to a generic checklist when the diff context is missing — ask instead
-
-## References
-
-- **STRIDE threat model** — Microsoft Security Development Lifecycle, Shostack
-  *Threat Modeling: Designing for Security* (2014). Framing basis for the
-  Actors / Assets / Entry Points / Trust Boundaries / Abuse Cases rubric.
-  [learn.microsoft.com/en-us/security/engineering/threat-modeling-tool-threats](https://learn.microsoft.com/en-us/security/engineering/threat-modeling-tool-threats)
-- **OWASP ASVS v4.0.3** — Authorization (V4), Validation & Encoding (V5),
-  Session Management (V3) — default baseline for "Missing control" entries.
-  [owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)
-- **OWASP Top 10 2021** — A01 Broken Access Control, A04 Insecure Design,
-  A05 Security Misconfiguration — cross-reference when naming abuse cases.
-  [owasp.org/Top10/](https://owasp.org/Top10/)
-- [`authz-review`](../authz-review/SKILL.md),
-  [`data-exposure-review`](../data-exposure-review/SKILL.md),
-  [`security`](../security/SKILL.md),
-  [`security-audit`](../security-audit/SKILL.md) — sibling review / impl skills.

package/.agent-src/skills/token-optimizer/SKILL.md

@@ -1,115 +0,0 @@
----
-model_tier: medium
-name: token-optimizer
-description: "Use BEFORE any verbose CLI run, large file read, doc conversion, or near-context handoff — single decision tree keyed by intent that cites the canonical token-saving asset. Consult before the action."
-domain: process
-execution:
-  type: assisted
-  handler: shell
-  allowed_tools: []
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# Token Optimizer — decision tree + catalog
-
-## Iron Law
-
-```
-CONSULT THIS SKILL BEFORE THE ACTION, NOT AFTER.
-THE TREE NAMES THE CANONICAL ASSET — DO NOT RESTATE OR DUPLICATE IT.
-```
-
-## When to use
-
-Proactively, BEFORE you:
-
-- Run a verbose CLI command (tests, linters, build, git log, large `grep`)
-- Read or paste a large document, log, or tool dump
-- Repeat the same tool call across many files / records
-- Approach the context-window limit and need to hand off
-- Make a cost-aware decision (which model, which budget, when to stop)
-
-Reactively when output already burned tokens — record the lesson, do
-not re-explore. Cite the leaf, move on.
-
-## Procedure
-
-1. **Classify intent** — match the situation to one branch of the tree below.
-2. **Cite the leaf** — name the canonical asset (rule, skill, or upstream link).
-3. **Apply** — execute the cited asset's contract; do NOT inline its content.
-4. **Verify** — output respects the cited Iron Law (redirect, wrap, batch, etc.).
-
-### Decision tree
-
-```
-INTENT
-├── Verbose CLI output incoming
-│     → cite [cli-output-handling](../../rules/cli-output-handling.md)
-│       (Iron Law: redirect / tail / grep / wrap)
-│     → cite [rtk-output-filtering](../rtk-output-filtering/SKILL.md)
-│       (rtk wrapper, 60-90% savings on tests/linters/git)
-│
-├── Large document or paste (PDF, DOCX, HTML, transcript)
-│     → cite markitdown (upstream: https://github.com/microsoft/markitdown)
-│       Convert FIRST, then read the markdown — never paste raw binary.
-│
-├── Repeated tool-call across N targets
-│     → cite [token-efficiency](../../rules/token-efficiency.md)
-│       (batch, parallelize, prune; one tool call > many)
-│
-├── Near context limit, work not finished
-│     → cite [agent-handoff](../../../.claude/skills/agent-handoff/SKILL.md)
-│       (structured handoff envelope; resume in fresh chat)
-│
-└── Cost-aware decision (model pick, budget, stop-criterion)
-      → cite /cost:report (when shipped) — until then, fall back to
-        [token-efficiency](../../rules/token-efficiency.md) and
-        [direct-answers § Brevity by Default](../../rules/direct-answers.md)
-```
-
-## Catalog
-
-| Asset | Path | Trigger keywords | What it does |
-|---|---|---|---|
-| `cli-output-handling` | `.agent-src.uncondensed/rules/cli-output-handling.md` | `verbose`, `tail`, `grep`, `CLI` | Wrap-tail-grep contract for any verbose command |
-| `rtk-output-filtering` | `.agent-src.uncondensed/skills/rtk-output-filtering/SKILL.md` | `rtk`, `verbose`, `filter`, `wrap` | Project-local rtk filters; wrapper command |
-| `token-efficiency` | `.agent-src.uncondensed/rules/token-efficiency.md` | `redirect`, `verbose`, `concise`, `tool` | Batch + parallelize tool calls; brevity floor |
-| `agent-handoff` | `.claude/skills/agent-handoff/SKILL.md` | `handoff`, `fresh`, `chat`, `context` | Context envelope for fresh-chat continuation |
-| `direct-answers` | `.agent-src.uncondensed/rules/direct-answers.md` | `brevity`, `flattery`, `severity`, `tiered` | Iron-Law brevity floor (kernel) |
-| `markitdown` | upstream: github.com/microsoft/markitdown | `PDF`, `DOCX`, `HTML`, `convert` | Document → markdown converter (authoritative-link only) |
-| `/cost:report` | TBD — `road-to-ruflo-adoption.md § P1.2` | `cost`, `model spend`, `budget` | Per-session cost telemetry (planned) |
-
-## Output format
-
-1. Name the cited asset by its leaf id (e.g. `cli-output-handling`, `rtk-output-filtering`).
-2. State the Iron Law in one line; do NOT inline the asset's body.
-3. If multiple branches match, cite all relevant leaves (no merge, no rewrite).
-4. End with the action you take next, citing the asset that authorizes it.
-
-## Gotcha
-
-- Catalog rows live and die with their target asset. If you edit a
-  cited asset's trigger keywords or scope, update the matching row in
-  this skill in the same commit (enforced by
-  [`token-optimizer-maintenance`](../../rules/token-optimizer-maintenance.md)
-  rule + `scripts/check_token_optimizer_freshness.py` CI gate).
-- Tree must stay scannable (≤ 50 lines incl. labels). Catalog rows
-  carry the long form.
-- Authoritative-link assets (`rtk` upstream, `markitdown` upstream,
-  pricing constants) are never copied — always linked.
-
-## Do NOT
-
-- Do NOT inline content from a cited asset. If the leaf is "rtk does X",
-  the agent reads `rtk-output-filtering`. Duplication = drift = stale.
-- Do NOT replace any rule. The rules carry the Iron Laws; this skill
-  carries the lookup index.
-- Do NOT define new policies — every leaf must cite an existing rule,
-  skill, or upstream asset.
-- Do NOT consult this skill AFTER tokens were already burned — record
-  the lesson and move on.
-
-<!-- TELEMETRY: consulted=[uncomment + ISO timestamp on each consult] context=[CLI|doc|repeat|handoff|cost] -->

package/.agent-src/skills/upstream-contribute/SKILL.md

@@ -1,261 +0,0 @@
----
-model_tier: inherit
-name: upstream-contribute
-description: "Use when a learning, new skill, rule improvement, or bug fix from a consumer project should be contributed back to the shared agent-config package."
-domain: process
-execution:
-  type: assisted
-  handler: internal
-  allowed_tools: ["github"]
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# upstream-contribute
-
-## When to use
-
-- A new skill was created in a project that should be shared across all projects
-- A rule or skill improvement was discovered that benefits all consumers
-- A bug was found in a shared skill, rule, or command
-- The `learning-to-rule-or-skill` skill identified something worth upstreaming
-- An override was created locally and should become the new default
-- A project-specific skill/rule could be **generalized** to benefit all consumers
-- The `upstream-proposal` rule suggested a contribution and user agreed
-
-Do NOT use when:
-
-- **The user has NOT given explicit consent** — this is the #1 rule
-- The content already exists in the shared package
-- The learning is truly one-off and cannot be generalized
-
-## Goal
-
-Contribute a learning, skill, rule, or fix from a consumer project back to the
-shared `agent-config` package — with correct file placement, quality gates, and PR structure.
-
-## Core principles
-
-- **⛔ Consent first** — NEVER create a PR, branch, or any upstream action without explicit user approval
-- **Universality first** — the contribution must work for ALL consumers, not just one project
-- **Generalize when possible** — project-specific content CAN become universal with adaptation
-- **Evidence-based** — learnings must have occurred 2+ times or be clearly generalizable
-- **Complete pairs** — both uncondensed and condensed versions required
-- **Quality verified** — must pass linter before PR creation
-- **Local benefit immediately** — use override for instant project benefit while PR is pending
-
-## Package repository
-
-The shared agent-config package lives at:
-
-```
-git@github.com:event4u-app/agent-config.git
-```
-
-GitHub: `https://github.com/event4u-app/agent-config`
-
-## Procedure
-
-### 0. Mandatory consent gate
-
-**This step is NON-NEGOTIABLE. No exceptions.**
-
-Before ANY upstream work (branch, files, PR), ask the user:
-
-```
-> 🔄 This [skill/rule/guideline] could improve the shared agent-config package.
-> [Brief explanation of what would be contributed and why it's valuable]
->
-> 1. Yes — create an upstream PR
-> 2. No — keep it project-local only
-```
-
-- **If user picks 2** → STOP. Do not mention upstream again for this item.
-- **If user picks 1** → continue with the procedure below.
-- **If `project.upstream_repo` is empty in `.agent-settings.yml`** → ask the user to configure it first.
-- **NEVER skip this step**, even if the user previously agreed to other contributions.
-
-### 1. Determine contribution type
-
-| Type | Uncondensed path | Condensed path |
-|---|---|---|
-| **New skill** | `.agent-src.uncondensed/skills/{name}/SKILL.md` | `.augment/skills/{name}/SKILL.md` |
-| **New rule** | `.agent-src.uncondensed/rules/{name}.md` | `.augment/rules/{name}.md` |
-| **New command** | `.agent-src.uncondensed/commands/{name}.md` | `.augment/commands/{name}.md` |
-| **New guideline** | `.agent-src.uncondensed/guidelines/{category}/{name}.md` | `.augment/guidelines/{category}/{name}.md` |
-| **Update to existing** | Same path as original | Same path as original |
-
-### 2. Apply locally as override (immediate benefit)
-
-Create an override so the project benefits immediately:
-
-```
-agents/overrides/{type}/{name}.md
-```
-
-With frontmatter:
-
-```yaml
----
-overrides: {type}/{name}
-mode: replace  # or extend
----
-```
-
-This step is optional if the change is low-urgency.
-
-### 2b. Generalize project-specific content (if needed)
-
-If the content is project-specific but could be made universal:
-
-1. **Identify project-specific parts** — domain names, local paths, project conventions
-2. **Abstract them** — replace with generic patterns, configurable values, or examples
-3. **Show the user the diff** — original vs. generalized version
-4. **Get approval** — user must confirm the generalized version is correct
-
-Example: A project-specific "import-csv" skill → generic "file-import" skill with configurable format.
-
-### 3. Prepare the upstream contribution
-
-The agent needs access to the package repository. Ask the user:
-
-```
-> The improvement should go to the shared agent-config package.
-> I need to create a PR in `event4u-app/agent-config`.
->
-> 1. I have the package repo cloned locally — tell me the path
-> 2. Clone it for me into a temp directory
-> 3. I'll handle the PR manually — just give me the files
-```
-
-**Option 1:** User provides path → work directly in that repo.
-
-**Option 2:** Clone into temp directory:
-
-```bash
-git clone git@github.com:event4u-app/agent-config.git /tmp/agent-config-upstream
-cd /tmp/agent-config-upstream
-```
-
-**Option 3:** Output the file contents as copyable blocks for the user.
-
-### 4. Create branch and files
-
-```bash
-cd {package-repo-path}
-git checkout main && git pull
-git checkout -b feat/skills/{name}  # or fix/rules/{name}, etc.
-```
-
-Create both files:
-
-- **Uncondensed version** → `.agent-src.uncondensed/{type}/{name}` (full, verbose, human-readable)
-- **Condensed version** → `.augment/{type}/{name}` (token-efficient, preserving all code blocks,
-  headings, frontmatter, validation, gotchas)
-
-For skills, the condensed version should be 40-60% shorter than uncondensed.
-For rules and commands, they are usually copied 1:1 (no condensation).
-
-### 5. Ensure file quality
-
-The files must:
-
-- Have correct YAML frontmatter (`name`, `description`, `source: package`)
-- NOT contain project-specific references (no domain names, local paths, FQDNs)
-- Follow the skill/rule/command template structure
-- Have exactly one trailing newline
-
-### 6. Run quality gates (if working in the package repo)
-
-```bash
-python3 scripts/skill_linter.py --all          # 0 FAIL required
-python3 scripts/check_condensation.py            # No errors for this file
-python3 scripts/condense.py --generate-tools    # Regenerate symlinks
-bash scripts/condense.sh --check                # .agent-src/ in sync with source
-bash scripts/condense.sh --check-hashes         # All hashes match
-```
-
-If not in the package repo, note that these checks will run in CI after the PR is created.
-
-### 6b. Proposal gate — MANDATORY when a proposal doc exists
-
-If the contribution originates from a proposal under `agents/proposals/`
-(produced by `learning-to-rule-or-skill` via the pipeline in
-[`self-improvement-pipeline`](../../../docs/guidelines/agent-infra/self-improvement-pipeline.md)),
-run the Stage-4 gate before opening the PR:
-
-```bash
-./agent-config proposal:check agents/proposals/{slug}.md
-```
-
-**Hard refusal rule:** if `./agent-config proposal:check` exits non-zero, STOP —
-do not create the branch, do not push, do not open the PR. Surface the
-findings to the user, ask them to fix the proposal (add evidence,
-remove TODO markers, complete required sections), then rerun.
-
-When no proposal doc exists (small fix, typo, pure bug-fix), skip this
-step and document the rationale in the PR body under the Promotion
-Gate.
-
-### 7. Commit and create PR
-
-Branch naming: `feat/skills/{name}`, `fix/rules/{name}`, `feat/commands/{name}`
-
-Commit message format:
-
-```
-feat(skills): add {name} skill
-fix(rules): improve {name} rule — {what changed}
-feat(commands): add {name} command
-```
-
-PR title: Same as commit message.
-
-PR body must use the package's PR template with these gates:
-
-- **Promotion Gate** — learning occurred 2+ times, improves correctness, prevents real failure
-- **Quality Gate** — linter passes, tests pass
-- **Universality Gate** — no project-specific assumptions, benefits all consumers
-- **Completeness Gate** — both versions present, symlinks regenerated
-
-### 8. After merge — clean up override
-
-Once the PR is merged and the package is updated in the project:
-
-```bash
-# In the consumer project
-rm agents/overrides/{type}/{name}.md
-composer update event4u/agent-config  # or npm update
-```
-
-The shared version now replaces the local override.
-
-## Output format
-
-1. Summary of what is being contributed (type, name, why)
-2. File contents for both uncondensed and condensed versions
-3. If working in the package repo: branch name, commit message, PR title
-4. If Option 3: copyable file blocks for the user to paste
-5. Reminder to clean up local override after upstream merge
-
-## Gotcha
-
-- Agent in consumer project doesn't know the package repo URL — this skill provides it
-- Agent may try to edit `.augment/` in the consumer project — that's read-only (symlinked)
-- Agent may forget the condensed version — both are mandatory
-- Agent may include project-specific references in the skill — must be universal
-- The `source` field in frontmatter must be `package`, not `project`
-- Agent may not have git access to the package repo — Option 3 handles this gracefully
-
-## Do NOT
-
-- **Do NOT create any upstream artifact without explicit user consent** — this is the #1 rule
-- **Do NOT open a PR if `./agent-config proposal:check` blocks** — fix the proposal first (step 6b)
-- Do NOT edit `.augment/` in the consumer project — it's managed by the package
-- Do NOT submit project-specific content without generalizing it first
-- Do NOT skip the condensed version — both files are mandatory
-- Do NOT forget to clean up the local override after upstream merge
-- Do NOT bypass quality gates — they exist for a reason
-- Do NOT assume consent from a previous contribution — ask every time

package/.agent-src/templates/AGENTS.md

@@ -1,34 +0,0 @@
-# {{project_name}}
-
-<!--
-  Fill placeholders or run `/agents init`, then delete this
-  comment. Iron Law — capability bullets, not path lists; paths rot.
-  Tool stubs (`CLAUDE.md`, `GEMINI.md`, `.cursorrules`) link here.
-  Anatomy + recipes: `.augment/contexts/contracts/agents-md-anatomy.md`.
--->
-
-> {{project_description}}
-
-## Layers
-
-| Layer | Location | Edits |
-|---|---|---|
-| Installed package | `.augment/`, `.agent-src/` | hands-off — managed by `event4u/agent-config` |
-| Project layer | `agents/`, `agents/overrides/`, `.agent-settings.yml` | your customizations and config |
-
-## Pointers
-
-- **Filling out this AGENTS.md** — section templates, capability bullets, multi-agent entry flow, monorepo per-package layout: [`.augment/contexts/contracts/consumer-agents-md-guide.md`](.augment/contexts/contracts/consumer-agents-md-guide.md).
-- **Behavior rules (always active)** — Iron Laws and routed rules that fire automatically while you work in this project: [`.augment/rules/`](.augment/rules/).
-- **Skills (on-demand expertise)** — domain skills surfaced by description; invoked when their trigger fires: [`.augment/skills/`](.augment/skills/).
-- **Commands (workflows)** — slash-commands the agent runs end-to-end (`/work`, `/implement-ticket`, `/commit`, `/create-pr`, …): [`.augment/commands/`](.augment/commands/).
-- **Project-specific docs** — your own architecture notes, roadmaps, sessions, contexts: [`agents/`](agents/).
-
-## Emergency triage — read this when nothing else is reachable
-
-1. **What is this repo?** — Consumer project; agent-config is installed as a shared skill / rule / command suite at `.augment/` and `.agent-src/`.
-2. **What language?** — Project-specific; agents mirror the user's language at runtime.
-3. **Where do I edit agent-config?** — Do not edit `.augment/` or `.agent-src/` here; they are installed artifacts. Project edits live in `agents/` and project source.
-4. **Lint / test / sync entry point?** — Project-specific (see project README); agent-config reinstalls via `composer update event4u/agent-config` or `npm update @event4u/agent-config`.
-5. **Where do the always-active rules live?** — `.agent-src/rules/` (kernel = 9 Iron-Law rules; tier-1 / tier-2 routed via `.agent-src/router.json`).
-6. **Per-module agent docs?** — If `modules.enabled: true`, each module under `modules.root_paths` may carry its own `{agent_folder}/` (default `agents/`). See `module-management` skill.

package/.agent-src/templates/agents/.gitattributes.fragment

@@ -1,16 +0,0 @@
-# Agent memory — append-only JSONL, union-merged.
-# Append this block to the consumer project's root .gitattributes.
-# See: agents/roadmaps/road-to-memory-merge-safety.md
-
-# Intake layer — agent-written, append-only. Union merge concats both
-# sides on conflict instead of failing. Reader deduplicates by id.
-agents/memory/intake/*.jsonl merge=union eol=lf
-
-# Curated memory — content-addressed drop-ins. One file per entry.
-# Normal merge is fine; filename collisions are content-identity.
-agents/memory/ownership/*.yml              text eol=lf
-agents/memory/historical-patterns/*.yml    text eol=lf
-agents/memory/domain-invariants/*.yml      text eol=lf
-agents/memory/architecture-decisions/*.yml text eol=lf
-agents/memory/incident-learnings/*.yml     text eol=lf
-agents/memory/product-rules/*.yml          text eol=lf