@event4u/agent-config 6.1.0 → 7.0.1

package/dist/agent-src/skills/brand-strategy/SKILL.md

@@ -0,0 +1,83 @@
+---
+model_tier: inherit
+name: brand-strategy
+description: "Ground a brand strategy from the corpus — archetype, opposable positioning, voice and tone, messaging framework. Use to decide who a brand is for, what it stands for, and how it sounds."
+domain: engineering
+personas:
+  - brand-strategist
+workspaces:
+  - engineering
+packs:
+  - brand
+trust:
+  level: professional
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# brand-strategy
+
+Grounding skill. Consults the brand corpus to surface archetype, positioning, voice/tone, and messaging constraints. Output is a constraint set the human confirms — never final brand copy — then handed to brand-identity and brand-to-tokens.
+
+## When to use
+
+- Deciding brand archetype, opposable positioning, voice/tone, or messaging framework before any identity work begins.
+- Before invoking brand-identity — the confirmed constraint set is its required input.
+- When a brief lacks a named audience, an opposable difference, or supporting proof.
+- When a brand refresh or extension needs grounding before token changes.
+
+## Procedure
+
+1. **Pressure-test the brief.** Is the audience named (not "everyone")? Is the difference opposable (could a competitor claim the opposite)? Is there at least one proof point? If any are missing, challenge — do not proceed on a vague brief.
+
+2. **Ground via the corpus.** Run the corpus engine for each required domain. Start with archetype, then voice, then messaging:
+
+```bash
+python3 <skills-root>/corpus-grounding/scripts/ground.py search \
+  --manifest <skills-root>/brand/data/manifest.json \
+  "<sector + audience + intent>" --domain archetype --json
+```
+
+   Repeat with `--domain voice` and `--domain messaging`. Each call returns ranked rows with `confidence` and `evidence_gap`.
+
+3. **Read confidence and evidence gaps.** Before trusting any row, read `confidence` and every `evidence_gap` entry verbatim. Low-confidence rows must be surfaced as gaps — never silently promoted.
+
+4. **Draft the constraint set.** Produce:
+   - An **opposable positioning statement** naming the audience AND a difference a competitor could legitimately claim the opposite of.
+   - A **voice profile**: 3-5 traits, each with a do and a don't.
+   - A **chosen messaging framework** (problem-solution, jobs-to-be-done, category creation, etc.) with a rationale sentence.
+
+5. **Surface gaps and low-confidence calls.** Name every evidence gap and every row below the confidence threshold. Flag where the corpus was thin.
+
+6. **Human confirms.** Present the full constraint set. Wait for confirmation before handing off. Do not proceed autonomously.
+
+7. **Hand off.** Pass the confirmed constraint set to brand-identity (identity execution) and brand-to-tokens (DTCG token emission).
+
+## Output format
+
+1. Named archetype cited to the corpus row (domain, row id, confidence).
+2. One-line opposable positioning statement (audience + difference).
+3. Voice profile: 3-5 traits, each with a do/don't pair, plus chosen messaging framework with rationale.
+4. Confidence label (High / Medium / Low) and every `evidence_gap` from the corpus verbatim.
+
+## Do NOT
+
+- Author final taglines, brand names, or headlines as decided output — those are identity artifacts.
+- Invent values or traits absent from the corpus or the consumer's existing brand.
+- Accept a brief with no named audience, no opposable difference, and no proof point.
+- Override the consumer's existing brand tokens or voice — they are the source of truth; this skill grounds net-new or refresh decisions only.
+
+## Gotcha
+
+- The corpus grounds pre-action selection, not validation. Post-production consistency checking belongs to brand-consistency, not here.
+- "Premium + approachable + innovative" is three briefs, not one. Force the trade-off before drafting a positioning statement.
+- An empty corpus result is legitimate signal — surface the gap and ask whether to proceed with a thin foundation or pause for more evidence.
+
+## See also
+
+- [`brand`](../brand/SKILL.md) — the corpus this skill grounds against.
+- [`brand-identity`](../brand-identity/SKILL.md) — consumes the confirmed strategy.
+- [`brand-to-tokens`](../brand-to-tokens/SKILL.md) — emits the DTCG token source of truth.
+- [`corpus-grounding`](../corpus-grounding/SKILL.md) — the shared engine.

package/dist/agent-src/skills/brand-strategy/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "skill": "brand-strategy",
+  "last_eval": "2026-06-16",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers grounding brand strategy (archetype, positioning, voice, messaging). Should-not covers near-miss neighbors.",
+  "queries": [
+    {"q": "which brand archetype fits a B2B SaaS startup targeting mid-market ops teams", "trigger": true},
+    {"q": "write an opposable positioning statement for our challenger brand", "trigger": true},
+    {"q": "define the voice and tone profile for our brand — what do we sound like and what do we never say", "trigger": true},
+    {"q": "which messaging framework should we use — jobs-to-be-done or category creation", "trigger": true},
+    {"q": "who is this brand actually for and what makes us different from the obvious competitors", "trigger": true},
+    {"q": "what UI style and colour palette should the dashboard use", "trigger": false, "note": "frontend style grounding -> design-intelligence"},
+    {"q": "generate a logo image for our new product line", "trigger": false, "note": "asset generation -> logo-generation"},
+    {"q": "emit our brand colours as CSS custom properties and a DTCG token file", "trigger": false, "note": "token emission -> brand-to-tokens / design-tokens"},
+    {"q": "check whether this landing page copy is consistent with our brand voice", "trigger": false, "note": "validation -> brand-consistency rule"},
+    {"q": "audit how consistently our brand is applied across our marketing site and product", "trigger": false, "note": "audit -> brand-audit"}
+  ]
+}

package/dist/agent-src/skills/brand-to-tokens/SKILL.md

@@ -0,0 +1,102 @@
+---
+model_tier: inherit
+name: brand-to-tokens
+description: "Derive a DTCG .tokens.json source of truth from confirmed brand decisions, emit CSS vars + Tailwind via design-tokens, and export locked brand deck templates. Use to turn a brand identity into tokens."
+domain: engineering
+personas: []
+workspaces:
+  - engineering
+packs:
+  - brand
+trust:
+  level: professional
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# brand-to-tokens
+
+> The brand→token derivation — the **first consumer demand** that closes the
+> ADR-061 §8 deferral. Takes a confirmed [`brand-identity`](../brand-identity/SKILL.md)
+> constraint set and produces a DTCG `.tokens.json` **source of truth**, then
+> hands it to the [`design-tokens`](../design-tokens/SKILL.md) toolchain to emit
+> CSS vars + Tailwind. The same `.tokens.json` is the export that pack-ai-image
+> brand-asset generation and the greenfield scaffold seed consume (B → A;
+> contract: [`brand-token-consumption`](../../../docs/contracts/brand-token-consumption.md)).
+
+## When to use
+
+- A confirmed brand identity (colour story, type story, spacing) needs to become
+  a maintained token system.
+- A consumer asks to "turn the brand into tokens / CSS variables / a theme."
+- Before pack-ai-image brand-asset generation or a greenfield scaffold needs the
+  `.tokens.json` export.
+
+## Procedure
+
+1. **Take the confirmed brand-identity constraint set** — colour story (roles +
+   values), type story (heading/body classes), spacing/radius intent. If a
+   consumer brand profile already registers values, those win
+   ([`brand-source-of-truth`](../../rules/brand-source-of-truth.md)).
+2. **Author `.tokens.json`** on the `design-tokens` 3-layer DTCG model
+   (`$value` / `$type`): brand palette → `primitive.color.*`; brand roles
+   (primary, accent, surface, destructive) → `semantic.color.*` referencing the
+   primitives; per-widget needs → `component.*`. Add `dark.semantic.*` overrides.
+   Type tokens come from [`typography-system`](../typography-system/SKILL.md)
+   stage-2 (archetype → pairing-filter), added under the `typography` section.
+3. **Generate** CSS vars + Tailwind through the toolchain:
+
+   ```bash
+   python3 <skills-root>/design-tokens/scripts/tokens.py generate \
+     --config .tokens.json -o assets/design-tokens.css
+   python3 <skills-root>/design-tokens/scripts/tokens.py generate \
+     --config .tokens.json --format tailwind
+   ```
+
+4. **Validate** — `python3 <skills-root>/design-tokens/scripts/tokens.py
+   validate --dir src/` until clean (exit 0 is the evidence); convert
+   hardcoded values to `var(--token)`.
+5. **Export the deck templates** — emit the locked-variable brand deck
+   templates from [`templates/`](templates/) — `marp-brand-deck.md.example`
+   (copy to `.md` to use) and `reveal-brand-deck.yaml` — substituting the brand
+   variables from `.tokens.json`. No render engine is owned (decision 7); the
+   templates feed the user's own deck tool.
+6. **Publish `.tokens.json`** as the source of truth other surfaces read
+   (pack-ai-image generation, greenfield scaffold) per the consumption contract.
+
+## Output format
+
+1. `.tokens.json` — DTCG 3-layer (primitive → semantic → component) + `dark.semantic` + `typography`, every value `{$value, $type}`.
+2. Generated `design-tokens.css` + the Tailwind `theme.extend` snippet.
+3. `validate` evidence — exit 0, or the `token_violation` findings handed to polish.
+4. The exported brand deck templates (Marp + reveal) with brand variables locked from the tokens.
+
+## Gotcha
+
+- **`.tokens.json` is the single source — never hand-edit the generated CSS or a
+  consumer-side copy.** pack-ai-image generation and the greenfield scaffold read
+  this file; a hand-edited downstream copy silently drifts from the brand.
+- **Derive, do not invent.** Every token traces to a brand-identity decision or
+  the consumer's existing brand; a value with no brand provenance is off-brand
+  ([`brand-consistency`](../../rules/brand-consistency.md) will flag it).
+- Deck templates **lock** brand variables — never inline a raw hex/font in a
+  template; reference the token so the deck stays on-brand when tokens change.
+
+## Do NOT
+
+- Do NOT generate marks or assets here — this skill emits tokens + templates;
+  [`logo-generation`](../logo-generation/SKILL.md) / `brand-asset-generation`
+  generate the marks from the tokens (B → A, never inverted).
+- Do NOT hand-edit generated CSS — `.tokens.json` is the source.
+- Do NOT let components reference primitives directly — semantic layer between.
+- Do NOT own a slide-render engine — export validated templates only (decision 7).
+
+## See also
+
+- [`brand-identity`](../brand-identity/SKILL.md) — supplies the constraint set this skill derives tokens from.
+- [`design-tokens`](../design-tokens/SKILL.md) — the DTCG toolchain that emits CSS/Tailwind from `.tokens.json`.
+- [`typography-system`](../typography-system/SKILL.md) — brand-aware stage-2 supplies the type tokens.
+- [`brand-token-consumption`](../../../docs/contracts/brand-token-consumption.md) — the read contract pack-ai-image and greenfield scaffold consume.
+- [`brand-consistency`](../../rules/brand-consistency.md) — validates emitted artifacts against this token source of truth.

package/dist/agent-src/skills/brand-to-tokens/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "skill": "brand-to-tokens",
+  "last_eval": "2026-06-16",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers deriving a DTCG .tokens.json source of truth from brand decisions and emitting CSS/Tailwind + deck templates. Should-not covers near-miss neighbors: generic token authoring without a brand frame, defining (not emitting) identity, generation, validation, and a deck-render engine.",
+  "queries": [
+    {"q": "turn our confirmed brand identity into design tokens", "trigger": true},
+    {"q": "derive a .tokens.json source of truth from the brand colours and type", "trigger": true},
+    {"q": "emit the brand as CSS variables and a Tailwind theme", "trigger": true},
+    {"q": "export brand deck templates with the brand variables locked", "trigger": true},
+    {"q": "generate the brand token system that pack-ai-image will consume", "trigger": true},
+    {"q": "author a generic 3-layer token system for this app (no brand)", "trigger": false, "note": "generic token authoring with no brand frame -> design-tokens"},
+    {"q": "define the colour story and type story for the brand", "trigger": false, "note": "defining the identity constraint set -> brand-identity"},
+    {"q": "generate a logo from these brand tokens", "trigger": false, "note": "asset generation -> logo-generation (pack-ai-image)"},
+    {"q": "check this component is using the brand tokens", "trigger": false, "note": "validation -> brand-consistency rule"},
+    {"q": "render this brand deck to PDF / build a slide engine", "trigger": false, "note": "no render engine is owned (decision 7) — templates only"}
+  ]
+}

package/dist/agent-src/skills/brand-to-tokens/templates/marp-brand-deck.md.example

@@ -0,0 +1,46 @@
+---
+# Marp brand deck template — locked brand variables.
+# Every visual value below references a brand token from .tokens.json
+# (var(--token)). Do NOT inline raw hex/fonts — that breaks brand sync.
+# Render with the user's own Marp tooling; no engine is owned here.
+marp: true
+theme: brand
+paginate: true
+style: |
+  :root {
+    --brand-bg: var(--semantic-color-background);
+    --brand-fg: var(--semantic-color-foreground);
+    --brand-primary: var(--semantic-color-primary);
+    --brand-accent: var(--semantic-color-accent);
+    --brand-font-heading: var(--typography-heading-font-family);
+    --brand-font-body: var(--typography-body-font-family);
+  }
+  section {
+    background: var(--brand-bg);
+    color: var(--brand-fg);
+    font-family: var(--brand-font-body);
+  }
+  h1, h2 {
+    font-family: var(--brand-font-heading);
+    color: var(--brand-primary);
+  }
+  strong { color: var(--brand-accent); }
+---
+
+# [Brand Name]
+
+Subtitle in the brand voice — replace with confirmed positioning line.
+
+---
+
+## Section title
+
+- Body copy in the brand body font, brand foreground colour.
+- **Emphasis** uses the brand accent token, never a raw hex.
+
+---
+
+## Closing
+
+Call to action in the brand voice. All colour and type come from
+`.tokens.json` via `var(--token)` — change the tokens, the deck restyles.

package/dist/agent-src/skills/brand-to-tokens/templates/reveal-brand-deck.yaml

@@ -0,0 +1,32 @@
+# reveal.js brand deck template — locked brand variables.
+# Values reference brand tokens from .tokens.json; the consumer's reveal
+# build injects assets/design-tokens.css so var(--token) resolves.
+# No render engine is owned here (decision 7) — this configures the user's reveal.
+deck:
+  title: "[Brand Name]"
+  # Inject the generated brand token stylesheet so var(--token) resolves.
+  css:
+    - assets/design-tokens.css
+  theme: brand
+
+# Brand variables are LOCKED to tokens — never inline a raw hex/font.
+brand:
+  background: "var(--semantic-color-background)"
+  text: "var(--semantic-color-foreground)"
+  heading: "var(--semantic-color-primary)"
+  accent: "var(--semantic-color-accent)"
+  font_heading: "var(--typography-heading-font-family)"
+  font_body: "var(--typography-body-font-family)"
+
+reveal:
+  controls: true
+  progress: true
+  transition: fade
+
+slides:
+  - heading: "[Brand Name]"
+    body: "Positioning line in the brand voice."
+  - heading: "Section title"
+    body: "Body copy in the brand body font; emphasis uses the accent token."
+  - heading: "Closing"
+    body: "Call to action. Restyle the whole deck by changing .tokens.json."

package/dist/agent-src/skills/canvas-design/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "canvas-design",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger queries. Should-trigger asks for static visual art (poster / cover / marketing visual). Should-not-trigger near-misses share design vocabulary but route elsewhere (fe-design, tailwind-engineer, voice-and-tone-design, release-comms).",
   "queries": [
     {"q": "Need a launch poster for next week's release announcement — A3 print, minimal style", "trigger": true},

package/dist/agent-src/skills/check-refs/SKILL.md

@@ -10,7 +10,7 @@ execution:
   allowed_tools: []
   command:
     - python3
-    - src/scripts/check_references.py
+    - src/scripts/check_references.ts
 workspaces:
   - agent-config-maintainer
 packs:
@@ -48,11 +48,11 @@ Invoke the skill through the runtime dispatcher so the `execution:` block in
 this skill's frontmatter governs the call:
 
 ```bash
-python3 scripts/runtime_dispatcher.py run --skill check-refs
+./scripts-run src/scripts/runtime_dispatcher run --skill check-refs
 ```
 
 The dispatcher resolves the request, the shell handler runs
-`python3 src/scripts/check_references.py`, captures stdout/stderr, and returns a
+`python3 src/scripts/check_references.ts`, captures stdout/stderr, and returns a
 typed `ExecutionResult`.
 
 ### 3. Verify the result
@@ -64,7 +64,7 @@ Check the returned `ExecutionResult`:
   line, and the offending ref, then fix the source or update the target
 - `status: timeout` → the checker exceeded `timeout_seconds` — investigate
 - `status: error` → interpreter or script missing — confirm `python3` and
-  `src/scripts/check_references.py` are available at the repository root
+  `src/scripts/check_references.ts` are available at the repository root
 
 ## Output format
 
@@ -87,7 +87,7 @@ Check the returned `ExecutionResult`:
 
 ## Do NOT
 
-- Do NOT invoke `src/scripts/check_references.py` directly when the intent is to
+- Do NOT invoke `src/scripts/check_references.ts` directly when the intent is to
   verify the runtime path — always go through the dispatcher so the
   `ExecutionResult` is produced and inspectable
 - Do NOT raise `timeout_seconds` to mask a slowdown — investigate which part

package/dist/agent-src/skills/code-review/SKILL.md

@@ -113,14 +113,7 @@ The checks below are stack-agnostic. For framework-specific conventions (PSR-12
 
 ### The response pattern
 
-When receiving code review feedback, follow this sequence:
-
-1. **READ** — Complete feedback without reacting.
-2. **UNDERSTAND** — Restate the requirement in your own words (or ask if unclear).
-3. **VERIFY** — Check the suggestion against codebase reality.
-4. **EVALUATE** — Is it technically sound for THIS codebase?
-5. **RESPOND** — Technical acknowledgment or reasoned pushback.
-6. **IMPLEMENT** — One item at a time, test each.
+Constraint: **understand each comment fully before touching code, verify it against codebase reality, and implement one item at a time (test each).** Restate anything ambiguous in your own words — or ask. Push back with technical reasoning when a suggestion is unsound for *this* codebase rather than complying reflexively.
 
 If **any item is unclear**, STOP — do not implement anything yet. Items may be related;
 partial understanding leads to wrong implementation.
@@ -161,13 +154,7 @@ How: Use technical reasoning, not defensiveness. Reference working tests/code.
 
 ### Addressing PR comments systematically
 
-When working through review comments on a PR:
-
-1. **List** all comments and review threads (`gh pr view --comments`).
-2. **Categorize**: blocking → simple fixes → complex fixes.
-3. **Clarify** anything unclear BEFORE implementing.
-4. **Fix** one at a time, test each.
-5. **Reply in the thread** — not as a top-level PR comment.
+Constraint: **clarify anything unclear before implementing, fix one item at a time (test each), and reply in each review thread** — not as a top-level PR comment. Triage first (blocking → simple → complex) so blockers land first; `gh pr view --comments` lists the threads.
 
 ```bash
 # Reply to a specific review comment thread
@@ -177,6 +164,10 @@ gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/replies \
 
 ## Output format
 
+1. Structure every finding by severity (Blocker / Suggestion / Nit) using the block below; never mix severities in one block.
+2. Group related findings; skip anything the project's linter or type-checker already catches — focus on logic, architecture, and judgment.
+3. End with a one-line verdict (approve / request-changes / comment) and a count of Blockers vs. Suggestions.
+
 When reviewing code, structure feedback by severity:
 
 ```

package/dist/agent-src/skills/command-writing/SKILL.md

@@ -194,10 +194,10 @@ multi-paragraph explanation, extract it into a skill and call it.
 
 ### 5. Validate
 
-* Run `python3 scripts/skill_linter.py src/agent-src/commands/{name}.md`
+* Run `./scripts-run src/scripts/skill_linter src/agent-src/commands/{name}.md`
   → 0 FAIL.
 * Run `bash scripts/condense.sh --sync` → regenerates `dist/agent-src/commands/{name}.md`.
-* Run `python3 scripts/condense.py --generate-tools` → creates the Claude symlink at
+* Run `./scripts-run src/scripts/condense --generate-tools` → creates the Claude symlink at
   `.claude/skills/{name}/SKILL.md`.
 * Run the full CI pipeline locally (see `Taskfile.yml` in this repo for
   the script list) — must exit 0 except for tolerated warnings.

package/dist/agent-src/skills/complexity-first-planning/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "complexity-first-planning",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers multi-component / uncertain work where a load-bearing unknown must be resolved first; should-not covers trivial / linear / fully-sequenced work and neighbors (feature breakdown, simple tests).",
   "queries": [
     {"q": "build a multi-tenant reporting pipeline with caching and access control — where do I start?", "trigger": true},

package/dist/agent-src/skills/context-authoring/SKILL.md

@@ -116,10 +116,10 @@ has to confirm or correct, not invent from scratch.
 
 ### Step 4: Validate
 
-1. Run `python3 scripts/check_portability.py` — project-specific content is
+1. Run `./scripts-run src/scripts/check_portability` — project-specific content is
    expected here, but the check catches accidental copy of other projects'
    identifiers.
-2. Run `python3 scripts/check_references.py` — cross-file links between the
+2. Run `./scripts-run src/scripts/check_references` — cross-file links between the
    five contexts must resolve.
 3. Confirm with the user: "is this accurate enough that a reviewer should
    treat it as the source of truth?" — anything less and a `<!-- TBD -->`

package/dist/agent-src/skills/context-document/SKILL.md

@@ -48,7 +48,7 @@ Unlike feature plans (future-focused) or roadmaps (task-focused), contexts are
 ├── skills-and-commands.md
 └── documentation-hierarchy.md
 
-agents/settings/contexts/                         # Project-wide contexts
+agents/settings/contexts/                                # Project-wide contexts
 ├── {context-name}.md
 
 {module_root}/{Module}/{agent_folder}/settings/contexts/ # Module-scoped contexts
@@ -66,9 +66,12 @@ agents/settings/contexts/                         # Project-wide contexts
 |---|---|---|
 | **Module** | Single module's structure and purpose | `client-software.md` |
 | **Domain** | Business domain across modules | `import-pipeline.md` |
-| **Service** | Complex service with its deps | `customer-service.md` |
+| **Service** | Complex service with its dependencies | `customer-service.md` |
 | **Integration** | External API/system integration | `probaus-api.md` |
 | **Infrastructure** | DevOps or infrastructure concern | `queue-system.md` |
+| **Knowledge card** | Trust-tiered cache of *expensive* (remote) structural evidence — negative facts + pointers durable, positive structure a hypothesis | `lodash.md`, `stripe-api.md` |
+| **Standards card (Class A)** | Coding standards **derived from real tooling config** — pointer + digest, `trust: high (config-derived)`, auto-refreshed when config changes; never a flattened claim | `coding-standards.md` (points at `ruff.toml`, `.editorconfig`) |
+| **Lesson card (Class C)** | Learned lesson — `symptom` (fact) split from `hypothesis` (decaying theory), `trust: low`, subject-not-person, anti-calcification decay; promoted only via human gate (accumulation layer is eval-gated) | `agents/memory/curated/lessons/<slug>.md` |
 
 ## Where to store contexts
 
@@ -77,8 +80,38 @@ agents/settings/contexts/                         # Project-wide contexts
 | About the `.augment/` system itself | `.augment/contexts/` (shared package) |
 | Project-wide or cross-module | `agents/settings/contexts/` |
 | Module-specific | `{module_root}/{Module}/{agent_folder}/settings/contexts/` (resolved via `modules.root_paths` + `modules.agent_folder`; Laravel example: `app/Modules/{Module}/agents/settings/contexts/`) |
+| **Knowledge card** (committed) | `agents/knowledge/<source>.md` — fill from the `knowledge-card` template |
+| **Evidence Report / probe dumps / absence log** (ephemeral) | `agents/memory/knowledge/session/` (gitignored, overwritten each task) |
 | If unsure | Ask the user |
 
+### Standards cards — Class A configured convention (Evidence v2)
+
+A **standards card** is a present-state context whose claims are **derived from the
+project's real tooling config** (`.editorconfig`, `eslint.config.js`, `pint.json`,
+`pyproject.toml`/`ruff.toml`, commit-lint, CI lint steps). It is `trust: high
+(config-derived)` — high *because* the config is the truth. Each standard is a
+**pointer + digest** (value + `source: file:key` + scope), never a flattened claim;
+conflicting configs surface as two pointers, never merged. Digest is **regenerated**
+when a source config's mtime/hash changes (auto-refresh, no human gate). Read for
+heuristics only, never to bypass a fresh structural read. Build with
+[`standards-from-config`](../standards-from-config/SKILL.md) skill; store under
+`agents/settings/contexts/`.
+
+### Knowledge cards — a specialized, evidence-disciplined context type
+
+A **knowledge card** extends this mechanism for the evidence-first discipline; it
+is **not** a second system. Unlike a normal context (a present-state snapshot a
+human curates), a card is governed: it is a cache of *expensive* remote evidence,
+**never a source of truth and never a build input**. Its trusted core is its
+**negative facts + pointers** (`trust: durable`); its positive structure is a
+per-line, last-verified **hypothesis** that loads as "Assumed (from card)" and
+must be re-confirmed against the live source before use. Cards pass the
+`check_knowledge_cards.py` pointer-CI (size ≤ 150, mandatory authoritative
+pointer, trust tagging, multi-evidence consistency). See
+[`source-discovery`](../source-discovery/SKILL.md) for when a structure is
+card-worthy and [`evidence-discipline`](../../agent-src/contexts/execution/evidence-discipline.md)
+for the full model.
+
 ### Shared vs. project-specific contexts
 
 **`.augment/contexts/`** — Part of the shared package. Describes the agent infrastructure:

package/dist/agent-src/skills/corpus-grounding/evals/triggers.json

@@ -1,5 +1,6 @@
 {
   "skill": "corpus-grounding",
+  "last_eval": "2026-06-16",
   "description": "5 should-trigger + 5 should-not-trigger queries. Should-trigger covers engine consultation + new-domain authoring; should-not-trigger covers domain skills that consult the engine themselves and reference/validation neighbors.",
   "queries": [
     {"q": "search the design corpus for fintech dashboard styles", "trigger": true},