@event4u/agent-config 2.18.0 → 2.20.0

package/.agent-src/skills/refine-ticket/SKILL.md

@@ -240,6 +240,9 @@ open questions surfaced>
 - **Critical Challenger** — <one paragraph>
 - **AI Agent** — <one paragraph>
 - **[qa]** — *(only when `--personas=+qa`)* <one paragraph>
+- **User: <label>** — *(only when `--user-type=<id>`)* <one paragraph
+  citing Daily Workflow / Vocabulary / Operational Constraints /
+  Ticket Red Flags from the loaded user-type>
 
 ## Orchestration notes
 

package/.agent-src/skills/subagent-orchestration/SKILL.md

@@ -51,6 +51,39 @@ Each mode has a decision row: when to use, when not, and the expected
 model pairing. Defaults come from
 [`subagent-configuration`](../../contexts/subagent-configuration.md).
 
+### Topology hints — per-mode communication shape
+
+Descriptive, not enforced. Documents the **expected agent-to-agent
+communication topology** so consumers can predict latency, failure
+modes, and where consensus is required. Cited from
+[`external-findings.md § 2`](../../../agents/audit-2026-05-14-north-star/external-findings.md)
+row 7 (Ruflo's `hierarchical, 6–8 agents, raft consensus` anti-drift
+default).
+
+| Mode | Topology | Anti-drift default | Notes |
+|---|---|---|---|
+| do-and-judge | `hierarchical` | 1 implementer · 1 judge · session-orchestrated | Two-node hub-and-spoke; orchestrator owns the loop. |
+| do-and-judge-two-stage | `hierarchical` | 1 implementer · 2 sequential judges | Stages are serialized; spec-judge gates quality-judge. |
+| do-in-steps | `ring` | N steps · 1 judge between each | Step N output → judge → step N+1 input; cycle on revise. |
+| do-in-parallel | `star` | 6–8 implementers · 1 judge · session-hub | Capped by `subagents.max_parallel`; judge runs once on union. |
+| do-competitively | `mesh` | 2–4 implementers · 1 judge | Implementers do not see each other; judge sees all candidates. |
+| judge-with-debate | `hierarchical-mesh` | 2 judges · 1 meta-judge | Judges debate (mesh edge); meta-judge reconciles (hierarchical). |
+| do-in-worktrees | `adaptive` | per-step topology of the underlying mode | Each worktree picks its own shape; chain is hierarchical. |
+
+**Anti-drift default** (Ruflo convention, descriptive only):
+`hierarchical, 6–8 agents, raft consensus`. Consumers free to
+override per orchestration — table is **starting point**, not a
+constraint. Topology is metadata for capacity planning, not
+runtime-enforced.
+
+**Glossary:**
+- `hierarchical` — orchestrator hub; agents reply to hub only.
+- `mesh` — agents see each other's outputs (e.g. competing diffs).
+- `hierarchical-mesh` — peer debate followed by hub reconciliation.
+- `ring` — output of step N feeds input of step N+1 in order.
+- `star` — N agents fan out from single hub; no peer comms.
+- `adaptive` — topology shifts per step; outer chain remains hub.
+
 ### 1. do-and-judge
 
 Implementer produces a diff; judge reviews; loop applies, revises, or

package/.agent-src/templates/agents/agent-project-settings.example.yml

@@ -39,7 +39,7 @@ schema_version: 1
 # CI guard: a release bump of `package.json` must update this value
 # in lockstep — see scripts/check_template_pin_drift.py (road-to-
 # portable-runtime-and-update-check P3.3).
-agent_config_version: "2.17.0"
+agent_config_version: "2.19.0"
 
 # --- Project identity ---
 project:

package/.agent-src/templates/skill-archive-note.md

@@ -0,0 +1,101 @@
+# Skill Archive Note Template
+
+> Template for `agents/archived-skills/<slug>.md`. Created during
+> `step-2-skill-inventory-rationalization.md`
+> Phase 4 execution. Every skill removed from
+> `.agent-src.uncompressed/skills/` MUST have a matching archive note
+> here — enforced by `scripts/lint_archived_skills.py`.
+
+## Instructions
+
+1. Create the file: `agents/archived-skills/{slug}.md`.
+2. Copy the template body below and fill every required field.
+3. Commit alongside the SKILL.md removal in the same PR (the linter
+   refuses to pass if the pair drifts).
+
+## Required frontmatter
+
+```yaml
+---
+slug: {skill-slug}            # the directory name that was removed
+archived_on: 2026-MM-DD        # UTC date of the removal commit
+last_seen_count: 0             # mentions_30d at archival time (from skill-usage-report.md)
+reason: unused                 # one of: unused, merged, superseded, deprecated
+replacement: none              # successor slug, or literal "none" if reason ∈ {unused, deprecated}
+last_known_callers:            # YAML list — files / commands / rules that cited this slug
+  - "none detected"            # or e.g. ".augment/rules/foo.md", "agents/roadmaps/bar.md"
+---
+```
+
+## Required body
+
+````markdown
+# {skill-slug}
+
+## Why archived
+
+{1–3 sentences. Cite the Phase 2 candidates-table row (overlap pair,
+activation counts, or both) that justified removal. Link the row.}
+
+## What replaces it
+
+{If `replacement: <successor>`: one paragraph on how the successor
+covers the source's triggers, and which trigger phrases it absorbed.
+Link the successor's SKILL.md.}
+
+{If `replacement: none`: one paragraph on why the capability is gone —
+no successor needed because the workflow itself was retired / merged
+into a router decision tree / handled inline by another rule.}
+
+## Last-known callers
+
+{If `last_known_callers:` is non-empty, one bullet per caller with a
+short note on whether the caller was updated, redirected, or left
+referencing the archive note. The lint gate fails if a caller still
+references the removed slug without pointing at this note.}
+
+## References
+
+- Candidates table row: [`skill-rationalization-candidates.md`](../metrics/skill-rationalization-candidates.md#{anchor})
+- Activation baseline: [`skill-usage-report.md`](../metrics/skill-usage-report.md)
+- Overlap pair (if applicable): [`skill-overlap.md`](../metrics/skill-overlap.md)
+````
+
+## Field semantics
+
+- **`slug`** — must match the removed directory name exactly. The
+  linter keys on this.
+- **`archived_on`** — UTC date string `YYYY-MM-DD`. Used for cohort
+  reporting (e.g. "skills archived in the May 2026 rationalization").
+- **`last_seen_count`** — `mentions_30d` value from the activation
+  report at the moment of archival. `0` is the dominant case; non-zero
+  values demand extra justification in *Why archived*.
+- **`reason`** — exactly one of:
+  - `unused` — `mentions_30d == 0` over the soak window.
+  - `merged` — content folded into another skill; trigger phrases
+    transferred.
+  - `superseded` — thin-redirect successor exists (`replaced_by`
+    relationship documented in the successor's frontmatter).
+  - `deprecated` — capability retired; no successor needed.
+- **`replacement`** — successor slug (must exist under
+  `.agent-src.uncompressed/skills/`) or literal `none`. The linter
+  validates the successor's existence.
+- **`last_known_callers`** — references found by
+  `scripts/check_references.py` at archival time. Empty list is valid
+  only when the check truly returned zero hits.
+
+## Lint contract
+
+`scripts/lint_archived_skills.py` enforces:
+
+1. Every file under `agents/archived-skills/*.md` (except the README)
+   has a frontmatter block with the six required fields.
+2. `reason` is one of the four allowed values.
+3. When `reason ∈ {merged, superseded}`, the `replacement` slug exists
+   under `.agent-src.uncompressed/skills/`.
+4. Every slug under `agents/archived-skills/` is *absent* from
+   `.agent-src.uncompressed/skills/` (no zombies).
+5. No SKILL.md present under `.agent-src.uncompressed/skills/`
+   references an archived slug as a router target.
+
+Run via `task lint-archived-skills`. Included in `task ci`.

package/.agent-src/user-types/README.md

@@ -0,0 +1,124 @@
+# User-types
+
+> Reusable **end-user simulation lenses** as a first-class primitive,
+> parallel to `personas/`. A user-type declares a *who*: a real
+> end-user of the software under review (a galabau field crew, a
+> truck driver, a metalworking shop). Skills consume them via
+> `--user-type=<id>` on the CLI.
+
+## Why this directory exists
+
+`personas/` answered one question well: *how* we review (qa,
+senior-engineer, critical-challenger, product-owner). It collapsed
+when "personas" like `galabau-field-crew` or `truck-driver` started
+landing — those are not review methodologies, they are the end-user
+viewpoint a methodology reviewer should adopt while reviewing.
+
+The two axes compose orthogonally:
+
+```
+/refine-ticket --personas=qa --user-type=truck-driver PROJ-123
+```
+
+QA methodology applied through a truck-driver end-user lens. The
+split is locked in [`../../docs/contracts/adr-user-types-axis.md`](../../docs/contracts/adr-user-types-axis.md).
+
+## What a user-type is — and is NOT
+
+- **Is**: a small Markdown file declaring an end-user simulation —
+  workflow, vocabulary, operational constraints, the questions only
+  this viewpoint would ask.
+- **Is NOT**: a persona. Personas describe review methodology, never
+  an end-user viewpoint.
+- **Is NOT**: an operational manual. User-types are review lenses
+  only — they flag ticket gaps, they never instruct a trade. No
+  welding procedures, no electrical work, no structural advice, no
+  dangerous how-to. The Anti-Patterns section in every file
+  encodes this floor.
+- **Is NOT**: an install-time filter. The vocabulary overlaps with
+  the install-time `user-types/` axis at the package root (see
+  [`../../docs/contracts/adr-install-user-type-axis.md`](../../docs/contracts/adr-install-user-type-axis.md)),
+  but the two live in different directories and consume different
+  config keys. Same word, different layer — by design.
+
+## Schema
+
+Locked in [`../../docs/contracts/user-type-schema.md`](../../docs/contracts/user-type-schema.md).
+
+- **Spine** — 7 sections (Focus · Daily Workflow · Vocabulary ·
+  Operational Constraints · Unique Questions · Ticket Red Flags ·
+  Anti-Patterns), ≤ 120 lines.
+- **Frontmatter** — `id · kind: user-type · description · version · source`.
+
+Run `task lint-skills` to enforce the schema, the size budget, and
+the Anti-Generic Quality Bar.
+
+## Anti-Generic Quality Bar (merge gate)
+
+Every user-type encodes **≥ 5 concrete, domain-specific review
+points** across `Daily Workflow`, `Vocabulary`, `Operational
+Constraints`, and `Ticket Red Flags`. Generic prose is REJECTED:
+
+- ❌ "consider mobile usability"  →  ✅ "capacitive touch fails with
+  wet leather gloves at 4 °C; tap targets ≥ 60 px or voice command"
+- ❌ "think about offline"  →  ✅ "no signal in cellar yards; queue
+  changes locally, conflict-resolve on the morning brief"
+
+Reviewer test: a generic reviewer persona could not have produced
+the `Unique Questions` or `Ticket Red Flags` of this file. If they
+could, the file is generic and must be rewritten.
+
+## Guardrails (encoded in every Anti-Patterns block)
+
+User-types are review lenses, not operational manuals. Every file's
+`## Anti-Patterns` section MUST explicitly forbid:
+
+- Trade-execution instructions (welding procedure, electrical work,
+  structural advice, anything that could harm if followed)
+- Dangerous how-to (chemical handling, equipment operation,
+  work-at-height procedures)
+- Medical / legal / engineering advice requiring a licensed
+  practitioner
+
+Allowed: workflow realism, ticket gap analysis, terminology
+correction, mobile / offline / safety / approval signals as
+ticket-requirement signals.
+
+## How skills use user-types
+
+CLI-only in v1 — skills do NOT declare a default `user-types:`
+frontmatter key. The migration path to v2 (skill-level default key)
+is documented in [`../../docs/contracts/adr-user-types-axis.md § Consequences`](../../docs/contracts/adr-user-types-axis.md).
+
+```
+/refine-ticket --user-type=truck-driver PROJ-123
+```
+
+If `--user-type=` is omitted, no end-user lens applies — persona
+review proceeds without simulation.
+
+## Authoring rules
+
+- Every user-type is drafted via the `artifact-drafting-protocol` rule.
+- Every user-type must pass the Anti-Generic Quality Bar (≥ 5
+  concrete review points, ≥ 3 Unique Questions falsifiable against a
+  ticket).
+- Project-specific user-types live in the consumer repo
+  (`.agent-src/user-types/` overrides), never in this package — the
+  three seeds shipped here are illustrative reference content.
+- Template: [`./_template/user-type.md`](./_template/user-type.md) (7 sections, ≤ 120 lines).
+
+## No-move policy
+
+No existing persona moves into this directory. The three seeds
+shipped here (`galabau-field-crew`, `metalworking-shop`,
+`truck-driver`) were born as user-types. Existing personas stay as
+personas. See [`../../docs/contracts/adr-user-types-axis.md § Migration`](../../docs/contracts/adr-user-types-axis.md).
+
+## Related
+
+- [`../../docs/contracts/user-type-schema.md`](../../docs/contracts/user-type-schema.md) — locked schema
+- [`../../docs/contracts/adr-user-types-axis.md`](../../docs/contracts/adr-user-types-axis.md) — the axis split decision
+- [`../../docs/contracts/adr-install-user-type-axis.md`](../../docs/contracts/adr-install-user-type-axis.md) — install-time `user_type` axis (distinct layer)
+- [`../personas/README.md`](../personas/README.md) — sister axis (methodology vs end-user)
+- [`../rules/artifact-drafting-protocol.md`](../rules/artifact-drafting-protocol.md) — mandatory per new user-type

package/.agent-src/user-types/_template/user-type.md

@@ -0,0 +1,95 @@
+---
+id: {user-type-id}
+kind: user-type
+description: "One sentence — who this lens simulates and the operational reality they bring; ≤ 160 chars."
+version: "1.0"
+source: project
+---
+
+# {Human-readable user-type name}
+
+## Focus
+
+One paragraph. Who this lens is, the operational context they work
+in (site, shop, vehicle, office), and what no persona catches.
+State the workflow shape and the time pressure that frames every
+decision they make.
+
+End with one sentence pinning the boundary: this lens is a **review
+lens only**, never an operational instruction source. No trade
+execution. No dangerous how-to.
+
+## Daily Workflow
+
+Concrete day-shape. What happens at 06:00, 10:00, 15:00. Who they
+talk to, what they touch, what they wait for. Avoid generic prose
+("they manage tasks"). Encode the actual rhythm.
+
+- {Morning routine — concrete trigger, tool, deliverable.}
+- {Mid-day workflow — concrete trigger, tool, deliverable.}
+- {End-of-day proof / close-out — concrete artefact + verification step.}
+
+## Vocabulary
+
+Domain terms the software must use (or must NOT substitute).
+Bilingual where the trade is bilingual. Plain-language over
+engineer-language where the user is non-technical.
+
+- {Term 1 — what it means, why the substitution fails.}
+- {Term 2.}
+- {Term 3.}
+
+## Operational Constraints
+
+Each constraint is a UI / flow signal, not generic empathy.
+
+- {Mobile / offline / connectivity / dead-zone constraint.}
+- {PPE / gloves / noise / lighting / weather constraint.}
+- {Time-pressure / hours-of-service / break-window constraint.}
+- {Hardware constraint — device, screen size, input mode.}
+- {Optional: legal / safety / certification constraint.}
+
+## Unique Questions
+
+Three or more questions no persona asks verbatim. Each must be
+falsifiable against the ticket under review.
+
+- {Question 1 — direct, scoped, answerable from the ticket.}
+- {Question 2.}
+- {Question 3.}
+- {Optional Question 4.}
+
+## Ticket Red Flags
+
+What this lens flags as missing or unrealistic when reviewing a
+ticket. Bullet list — each item names a concrete signal a generic
+reviewer would miss.
+
+- {Red flag 1 — concrete signal + why it matters in this domain.}
+- {Red flag 2.}
+- {Red flag 3.}
+
+## Anti-Patterns
+
+Non-negotiable. Guardrails are encoded here.
+
+- **Review-only, never operational.** No trade execution
+  instructions (welding procedure, electrical work, structural
+  advice). No dangerous how-to. No medical / legal / engineering
+  advice that requires a licensed practitioner.
+- **No generic prose.** "Consider usability" / "think about offline"
+  fails the Anti-Generic Quality Bar — every observation cites a
+  concrete signal.
+- {Anti-pattern 3 — domain-specific failure mode this lens refuses to validate.}
+- {Anti-pattern 4 — optional.}
+
+---
+
+*Author note (delete before publishing): this template targets the
+7-section spine locked in
+[`docs/contracts/user-type-schema.md`](../../../docs/contracts/user-type-schema.md).
+Stay within the **≤ 120 line** budget (file total, including
+frontmatter). Replace every `{placeholder}` with concrete content
+that passes the Anti-Generic Quality Bar (≥ 5 concrete review
+points; ≥ 3 Unique Questions). Run `task lint-skills` before
+commit.*

package/.agent-src/user-types/galabau-field-crew.md

@@ -0,0 +1,100 @@
+---
+id: galabau-field-crew
+kind: user-type
+description: "Landscape-build crew on site — gloves, mud, no-signal, billable-photo proofs, bilingual plain-German vocabulary."
+version: "1.0"
+source: project
+---
+
+# Galabau Field Crew
+
+## Focus
+
+Two- to four-person crew on a landscape / garden-build site —
+paver-laying, retaining walls, planting, irrigation. Phone or
+rugged tablet in a pouch, gloves on, lifting something heavy every
+fifteen minutes. Workday shaped by weather, delivery slots, and
+customer arriving unannounced for "just one more thing". No
+reliable signal on half the sites. Every customer-requested change
+is either billable later or silently swallowed; documentation at
+the moment of change is the only way that decision survives.
+
+Review lens only, never operational instruction source. No
+paver-laying procedure, no soil-prep chemistry, no structural
+advice on retaining walls.
+
+## Daily Workflow
+
+- 06:30 — depot pickup, materials loaded, route confirmed; lead
+  reads day plan once, on phone, gloves off.
+- 07:30–11:30 — execution on site; phone back in pouch. UI reads
+  happen at coffee breaks or when customer interrupts.
+- 11:30 — billable-change moment: customer asks for an extra step,
+  crew lead captures it as timestamped photo + short note +
+  ideally signature, **before** next task starts.
+- 15:30 — end-of-day proof: photo of finished section, geotagged,
+  uploaded if signal exists, queued offline if not.
+- 17:00 — depot return; office reconciles day from photos +
+  notes, not from memory.
+
+## Vocabulary
+
+- **Aufmass** — measured-on-site quantity that becomes invoice
+  basis; never substitute with "estimate" or "measurement".
+- **Nachtrag** — billable change-request added to a running job;
+  losing one = losing money, not just data.
+- **Sauberkeitsschicht** — gravel layer under pavers; plain-German,
+  not "base course".
+- **Plain-German over engineer-German.** Crew is bilingual (often
+  DE / PL / TR); noun must be the one on the delivery slip, not
+  the one in the BOQ.
+
+## Operational Constraints
+
+- **No signal on half the sites.** Every write must queue and sync;
+  every read must work from cache. Conflict resolution on sync is
+  a ticket requirement, not a nice-to-have.
+- **Capacitive touch fails with wet or dirty gloves.** Primary
+  flows survive with stylus, knuckle, or large-target taps. No
+  pinch-zoom on the critical path.
+- **Photo is the proof, not the form.** A billable-change flow
+  needing three text fields before camera opens loses changes
+  silently — crew defers, then forgets.
+- **Screen washout in direct sun.** High-contrast mode on by
+  default for outdoor flows, never opt-in via settings.
+- **Rugged hardware, slow CPU.** Animations and skeleton loaders
+  burn battery; crew runs 10+ hours per charge on the device.
+
+## Unique Questions
+
+- Does this flow survive a 4-hour offline window plus a sync with
+  conflicting edits from the office?
+- Can a gloved hand complete the primary action in one tap from
+  the home screen without typing?
+- Is there a photo-first path for capturing a billable change, or
+  does the form block the camera?
+- Is the noun on screen the one written on the delivery slip, in
+  the language the crew actually uses?
+
+## Ticket Red Flags
+
+- "User enters …" without specifying input mode — gloves rule out
+  the keyboard on the critical path.
+- Sync described as "auto" with no conflict-resolution UI sketched.
+- High-contrast / outdoor visibility treated as a settings toggle
+  rather than the default for outdoor flows.
+- No mention of what happens when the customer signature step is
+  refused or skipped.
+
+## Anti-Patterns
+
+- **Review-only, never operational.** No paver-laying procedure,
+  soil chemistry, structural retaining-wall advice, or anything a
+  licensed Galabauer must sign off.
+- **No generic prose.** "Consider offline support" fails the
+  Anti-Generic Quality Bar — every observation cites a concrete
+  signal (gloves, signal-loss, Nachtrag, Aufmass).
+- **No engineer-vocabulary substitution.** Renaming Nachtrag to
+  "change request" in the UI breaks the billing chain.
+- **No photo-after-form flows.** Photo must be reachable in one
+  tap from the moment customer asks for the change.

package/.agent-src/user-types/metalworking-shop.md

@@ -0,0 +1,105 @@
+---
+id: metalworking-shop
+kind: user-type
+description: "Shop-floor metalworking team — job travelers, material certs, machine-time gates, PPE/noise constraints on UI."
+version: "1.0"
+source: project
+---
+
+# Metalworking Shop
+
+## Focus
+
+Small-to-mid metalworking shop — laser-cut, press-brake, weld,
+finish. Two surfaces: shop-floor tablets bolted near machines
+(loud, dirty, gloves) and an office desktop where quoting,
+scheduling, and material-cert tracking happen. Shop runs on **job
+travelers** (route cards) — one per job following the work through
+every station, getting stamped, ending in the shipping bay.
+Material certificates (heat numbers, mill certs) must trace from
+incoming bar stock through to the customer; losing the chain
+breaks the audit and can void the order.
+
+Review lens only, never operational instruction source. No
+welding-procedure spec, no electrical guidance, no
+structural-engineering advice. Trade execution stays with the
+certified welder, the EHS officer, and the engineer.
+
+## Daily Workflow
+
+- 06:00 — shift starts, lead reviews day's travelers at office
+  desktop; priority shifts printed and pinned at the station.
+- 07:00–15:30 — execution per station; each station scans the
+  traveler QR or punches job number on tablet to start / pause /
+  complete time on that step.
+- Material check-in — incoming bar stock photographed with mill
+  cert; heat number bound to lot at moment of receipt, not later
+  from memory.
+- Safety sign-off — process steps requiring PPE or second-person
+  check (overhead crane, confined-space weld) cannot start until
+  sign-off is recorded on the tablet.
+- 15:30 — end-of-shift, lead reconciles open travelers, flags any
+  step where the material-cert chain is broken.
+
+## Vocabulary
+
+- **Job traveler / route card** — single canonical record that
+  moves with the part; never substitute with "ticket" or "task".
+- **Heat number / mill cert** — material identity; lose the link
+  and the part is unsellable to a regulated customer.
+- **Sign-off** — recorded, named, timestamped; "approved" without
+  a name fails audit.
+- **Setup vs run time** — booked separately on the machine;
+  merging them destroys costing accuracy.
+
+## Operational Constraints
+
+- **Shop-floor tablet bolted at the station.** Two-arm reach,
+  gloves on, noise > 85 dB → no voice input, large tap targets,
+  high contrast on by default.
+- **PPE prevents fine touch.** Welding gloves + safety glasses;
+  drop-down pickers with > 6 options are a fail mode.
+- **Machine-time is money.** A flow adding 30 seconds per
+  job-step start, run 200 times/day, costs the shop one
+  machine-hour per shift.
+- **Material-cert chain is regulatory.** Every step touching
+  material must capture or carry the heat-number link; breaking
+  it silently is the worst failure mode.
+- **Two-surface split.** Office desktop has Excel-grade density;
+  shop tablet has one-action-per-screen. Same flow cannot share
+  a layout.
+
+## Unique Questions
+
+- Does this flow carry the heat-number / material-cert link from
+  receipt to ship, with no manual re-entry step that can drop it?
+- Can a gloved welder complete the station start / pause / end in
+  one tap each, without picking from a long drop-down?
+- Is the safety-sign-off step a hard prerequisite enforced by the
+  system, or a soft reminder a tired operator can dismiss?
+- Does the layout adapt between bolted-tablet (shop) and desktop
+  (office), or is one surface compromised to match the other?
+
+## Ticket Red Flags
+
+- "User selects job from dropdown" — long list, gloves, no QR
+  alternative.
+- Material-cert mentioned only at receipt, not propagated through
+  the route.
+- Setup time and run time collapsed into a single "time on job"
+  field.
+- Safety sign-off treated as optional metadata rather than a gate.
+- One layout described for both surfaces without saying which.
+
+## Anti-Patterns
+
+- **Review-only, never operational.** No welding procedure (WPS),
+  no electrical work, no PPE selection guidance, no structural or
+  fatigue-engineering advice — those require certified humans.
+- **No generic prose.** "Consider shop-floor usability" fails the
+  Anti-Generic Quality Bar — every observation cites traveler,
+  heat number, sign-off, machine-time, or PPE.
+- **No collapsing setup-and-run time.** Costing depends on the
+  split; merging it for "UI simplicity" destroys the model.
+- **No silent loss of material-cert link.** A flow that lets the
+  chain break without an audit signal is rejected.