Help us improve
Share bugs, ideas, or general feedback.
From lynx
End-to-end app audit + auto-remediation loop combining the per-screen UX rigor of `ui-experience-audit` with the app-wide breadth of `full-functional-audit`. Keeps cycling — discover, audit, validate, fix in parallel, re-audit — until the codebase converges below a user-chosen defect threshold and survives a clean confirmation pass. Detects platform (iOS, web, full-stack) and routes tooling: `agent-browser` for every web interaction (never Playwright), `xcrun simctl` + `ios-validation-runner` patterns for iOS, real curl + DB checks for backends. Use whenever the request is "audit and fix the whole app", "find and fix every issue", "run the full audit until it passes", "complete UI/UX + functional sweep", "release-readiness pass with auto-fix", "production-readiness loop", "audit and remediate", "make the app pass", or "loop until clean". Supports solo-agent or parallel team-of-subagents execution — ask the user which at the start.
npx claudepluginhub krzemienski/lynx --plugin lynxHow this skill is triggered — by the user, by Claude, or both
Slash command
/lynx:full-ui-experience-auditThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A composite, looping audit-and-remediate workflow. It treats the app the way a
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Explores codebases via GitNexus: discover repos, query execution flows, trace processes, inspect symbol callers/callees, and review architecture.
Share bugs, ideas, or general feedback.
A composite, looping audit-and-remediate workflow. It treats the app the way a release manager would — find every screen, every interaction, every endpoint; audit each one for both UX quality and functional correctness; fix every defect the audit surfaces; and re-run the whole thing until the codebase is genuinely clean, not just "passing the parts we looked at".
This is the heaviest tool in the audit kit. Reach for it when the goal is the whole app, not a single screen, and when "find issues, hand them off, hope someone fixes them later" is not good enough.
full-functional-audit
does)ui-experience-audit's 5-phase protocol
(triage → visual → interactive → content → heuristics)functional-validation's
Iron Rule — real system, no mocks, evidence requiredfunctional-validation)IF the real system doesn't work, FIX THE REAL SYSTEM.
NEVER create mocks, stubs, test doubles, or test files.
NEVER write .test.ts, _test.go, Tests.swift, test_*.py, or any test harness.
ALWAYS validate through the same interfaces real users experience.
ALWAYS capture evidence. ALWAYS review evidence. ALWAYS write verdicts.
If you find yourself thinking "let me add a quick mock so this audit can pass",
stop and read no-mocking-validation-gates. That impulse is the bug.
This skill has two knobs the user controls per run. Don't assume — ask once at the start, then proceed.
Ask the user which severity floor they want before declaring the loop done. Common answers:
| Threshold | Stops when… | Good for |
|---|---|---|
critical-only | Zero CRITICAL findings + 1 clean pass | Hotfix / time-pressured release |
critical-high (recommended default) | Zero CRITICAL or HIGH + 1 clean pass | Normal release readiness |
critical-high-medium | Zero of those + 1 clean pass | Quality bar before a major launch |
zero-defects | Zero of any severity + 2 clean passes | Production audit, regulated build |
Whatever the user picks is binding for the entire run. Don't ratchet it up or down mid-loop — that's how false PASSes get rationalized into the verdict.
Ask: solo (you do every phase yourself, sequentially) or team (you act as lead and dispatch subagents in parallel)?
| Mode | When to use |
|---|---|
| Solo | Small apps (< ~5 screens), no subagent capability available, or the user explicitly wants tight single-context control |
| Team | Apps with many screens, when subagents are available, when wall-clock matters, or when the user asks for parallelization explicitly |
If the user is unsure, recommend solo for < 5 screens, team for more. Read
references/team-coordination.md if and only if team mode is chosen — solo
runs don't need it.
If team mode is requested but subagents aren't available in this
environment (e.g., claude.ai default, or no Task/dispatch tool exposed),
fall back to solo and tell the user. The skill is designed to degrade
gracefully — solo mode with a 50-screen app is slower but still correct;
team mode with no subagents is incorrect.
The Platform field in run-config.md is user-declared and
authoritative. The table below is a hint for auto-detection — if it
fits, use it; if it doesn't, the user picks. Each platform has a
different tooling stack and different evidence types.
| Indicator | Suggested platform | Web tool | UI evidence | Reference to load |
|---|---|---|---|---|
.xcodeproj, .xcworkspace, Package.swift | iOS / macOS | n/a | xcrun simctl screenshots + video | references/ios-protocol.md |
| React/Vue/Svelte/Next/Vite + no backend routes | Web | agent-browser | agent-browser screenshot | references/web-protocol.md |
| Frontend framework + REST routes / handlers | Full-stack | agent-browser | agent-browser + curl | BOTH web-protocol.md and the API section of functional-validation |
| React Native, Flutter, Expo | Cross-platform mobile | n/a (or agent-browser for web target) | xcrun simctl for iOS, simulator-equivalent for Android | references/ios-protocol.md + Android notes |
Apps that don't match any row cleanly — bare-Node http.createServer,
single-file Bun servers, exotic stacks — are still auditable. The user
declares the platform in run-config.md and the matching reference file
loads. Don't refuse to run because auto-detect didn't match.
agent-browser onlyFor every web interaction in this skill, use agent-browser. Not Playwright,
not Chrome DevTools MCP, not Puppeteer — agent-browser. The reasons are
practical: it's the tool the rest of this user's ecosystem standardizes on,
its @e1-style refs survive DOM changes better than CSS selectors picked
on the fly, and the daemon model means the browser session persists across
audit cycles without re-bootstrapping.
If something in references/ or a related skill mentions Playwright for web
work — translate it to agent-browser before executing. The patterns map
cleanly: playwright.click(selector) → agent-browser snapshot -i then
agent-browser click @eN.
Phase 0 Triage & setup (once)
─── loop start ─────────────────────────────
Phase 1 Discovery & inventory (once on cycle 1, refresh on each cycle)
Phase 2 Per-screen UX audit (parallel-safe: read-only)
Phase 3 Functional validation (mutex-coordinated)
Phase 4 Remediation (fix loop) (mutex-coordinated)
Phase 5 Convergence check → repeat from Phase 1, or proceed
─── loop exit ──────────────────────────────
Phase 6 Clean confirmation pass (one full cycle that finds nothing new)
+ final verdict
A cycle = one pass through Phases 1–5. Cycle counter starts at 1.
Goal: confirm the project will hold still long enough to audit it, and lock the run's configuration so every later phase has a single source of truth.
Six steps, in order. Detail and templates live in
references/phase-0-setup.md — read it on first cycle.
run-config.md — app name, platform, mode, threshold,
max-cycle cap, coverage axes (yes/no/not-supported per axis), base URL,
sim UDID, bundle ID. This is the source of truth every later phase
reads from.preflight skill if available; covers
build green, backend reachable, dev-tool sanity. Stop-the-world on
failure.references/ios-protocol.md;
web/full-stack uses references/web-protocol.md.agent-browser, xcrun simctl,
xcodebuild, git, jq, curl, repomix (with fallback). Don't
enter the loop with a missing required tool.repomix --style xml --compress per the
user's standing instruction; falls back to direct grep when not
installed.audit-evidence/ tree.Coverage axes use three values, not two:
yes — supported and audited (counts toward full coverage)no — supported but opted out this run (caps verdict at PASS (LIMITED COVERAGE))not-supported — feature genuinely absent (doesn't penalize the verdict)Don't fail an app for "missing" dark mode it never had. "Responsive but unoptimized" is not an axis state — that's a Phase 2 finding (poor mobile layout), not a missing feature.
Degraded mode (web only): if agent-browser is missing, Phase 0
sets degraded_mode: yes in run-config.md and the loop runs against
static HTML + CSS reads (Phase 2 in identify-and-delegate) and curl
checks (Phase 3 backend). Verdict caps at PASS (LIMITED COVERAGE) —
an unsupervised report on what can be inferred without live driving.
Better than refusing to run; honest about the coverage gap.
Goal: produce the structured inventory that drives every later phase,
and open findings.json for the cycle.
This is the same exploration that full-functional-audit's Phase 1 does —
follow that protocol. The summary:
/queue, backend registers /agent-queue) are real
findings — write them straight to cycle-NN/findings.json with
phase: "discovery". They go through the normal Phase 4 fix loop.cycle-NN/inventory.md using the format in
references/inventory-template.md. Each row: id, screen, interaction,
trigger, backend dep, priority (P0 core / P1 secondary / P2 edge).cycle-NN/findings.json with the schema in
references/inventory-template.md. Phase 1 cross-reference findings
are the first entries; Phase 2 and Phase 3 append.On cycles 2+: don't redo the whole inventory from scratch. Refresh it — re-scan for new screens / interactions added by Phase 4 fixes, mark removed ones, carry forward unchanged rows. This keeps cycle time bounded.
Goal: run ui-experience-audit's 5-phase protocol against every screen,
plus the depth visual passes in references/visual-experience-audit.md
that catch what a one-shot screenshot review misses.
This is the phase where audits actually catch the experience instead of producing checklists. Visuals and interaction are inseparable here — a button that looks tappable but isn't, a focus ring that's invisible, a dark-mode rendering that's illegible, an empty state that's blank where it should welcome — these are visual and experiential failures at once. The protocol below catches both classes by treating each as a required dimension of the audit, not as separate phases.
For each screen in the inventory:
visual-experience-audit.md: default,
hover (web), focus (always), active (CSS-inspected), disabled,
loading, success, error. Then capture the screen's variants:
empty, loading, populated, overflow, error, first-launch — using
the state-forcing recipes in that file. Capture in light AND dark
mode if dark is yes in run-config.md.agent-browser unavailable):
read the rendered HTML and CSS directly from source. Save as
<screen-slug>.html.snapshot. Run the static-analysis grep
playbook from visual-experience-audit.md — it catches the
contrast, false-affordance, missing-focus, and design-token-drift
bugs without needing the browser.ui-experience-audit with mode:
drive-interaction if a live system is reachable AND tooling is
availableidentify-and-delegate otherwise (correct in degraded mode)agent-browser diff screenshot --baseline <baseline.png>. For iOS:
ImageMagick compare. Differences ≥ 1% of pixels that aren't part
of the cycle's intended fixes are findings.cycle-NN/ux-reports/<screen-slug>.md
with separate sections for visual findings and experience
findings — the lead and any reviewer should be able to scan the
visual section in isolation.cycle-NN/findings.json with phase: "ux"
and the schema in references/inventory-template.md.After per-screen audits complete, run the cross-screen consistency
audit from visual-experience-audit.md — one pass per cycle, fast
(20-30 minutes for a 10-screen app), catches design-system drift that
no per-screen audit can: token consistency, type-scale, component
shape, nav continuity, modal style, iconography contact-sheet diff.
Findings here are usually CRITICAL or HIGH because drift is expensive
to fix later.
This phase is parallel-safe because the per-screen audits are read-only against the live system. In team mode, dispatch one subagent per screen group (each captures its own multi-state set); the lead reads every capture personally. In solo mode, walk screens sequentially.
Resource note: if screens share a single browser tab (web) or
simulator (iOS), parallel UX audit still serializes on the capture
step. The analysis after capture is what parallelizes. See
references/team-coordination.md for the full mutex matrix.
Goal: prove every interaction in the inventory actually does what it claims.
For each interaction:
ios-validation-runner for the timing playbook){"total": 12} is a HIGH findingcycle-NN/findings.json with cited evidence;
save raw evidence files into cycle-NN/functional-evidence/Web-specific: use agent-browser snapshot -i to get fresh @eN refs after
every navigation. Stale refs are the #1 false-FAIL on web. See
references/web-protocol.md for the canonical command sequence.
iOS-specific: status bar override, kill -SIGINT for video stop, --info --debug on log streaming — all the ios-validation-runner discipline applies.
See references/ios-protocol.md.
Degraded mode (web only): when agent-browser is unavailable, Phase 3
runs curl-only — every backend endpoint in the inventory gets a curl
request, status code captured, response body saved as evidence. Frontend
interactions can't be live-driven; instead, infer their wiring from code
(event handlers, fetch paths) and treat any handler-less affordance, any
fetch-to-unmapped-endpoint, and any 4xx/5xx response as a finding.
Evidence is curl JSONs and source-line citations, not screenshots.
This phase is mutex-coordinated: simulator and browser are EXCLUSIVE resources, code reads / curl checks are PARALLEL.
Goal: drive each finding from Phase 2 + Phase 3 down to PASS, in this cycle, before moving to Phase 5.
The remediation algorithm lives in references/fix-loop-protocol.md. The
short version, adapted from full-functional-audit's Phase 4 and
worktree-merge-validate's Immediate Remediation Protocol:
For each finding (priority order: CRASH > BACKEND > NAVIGATION > VISUAL > DATA > UX):
1. DIAGNOSE — read source, trace code path, identify root cause
2. CHECK FOR MOCK TEMPTATION — invoke no-mocking-validation-gates if you feel one
3. FIX — minimal correct change
4. BUILD — confirm it compiles
5. RE-VALIDATE — re-run the specific Phase 2 / Phase 3 step that failed
6. INVOKE gate-validation-discipline — cite specific evidence of the fix
7. COMMIT — one fix, one commit, descriptive message
8. NOTIFY — if in team mode, broadcast the fix to other agents
(a fix to shared infrastructure may invalidate their work)
Non-deferrable. Don't "log and continue." A finding that survives Phase 4 within a cycle blocks Phase 5 → which blocks the next cycle → which blocks the final verdict. The whole loop is built on the contract that Phase 4 actually fixes.
Parallelization rules (team mode only):
When in doubt, serialize. False parallelism creates false failures and wastes more time than it saves.
After Phase 4 closes out the cycle's findings, decide: loop again, or exit?
If cycle's exit findings count is ABOVE the user-chosen threshold:
→ loop back to Phase 1 (refresh inventory, re-audit)
If cycle's exit findings count is AT OR BELOW the threshold:
→ proceed to Phase 6
Track per cycle:
Finding ID stability: once an ID is assigned in any cycle, it never
changes. Cycle 2 may discover a new interaction I042 — I001 through
I041 keep their numbers. This is what makes stuck-state detection work
across cycles. Inventory diffs (+/-/~ rows in cycles 2+) preserve
IDs verbatim.
Stuck state: if two consecutive cycles produce the same set of open
finding IDs without progress, escalate to the user (see
references/fix-loop-protocol.md for the escalation language and the
user's three options). Don't grind forever; either the threshold is wrong,
the fix is harder than expected, or there's an upstream issue (third-party
API, infrastructure) that's outside the audit's power to fix.
Max-cycle cap: the run stops at max_cycles from run-config.md
(default 10) regardless of stuck-state detection. A run that hits the cap
without converging produces a FAIL (CYCLE-CAP REACHED) verdict in
Phase 6 with a complete cycle history — that's still useful output, just
not a PASS. The user can re-run with a higher cap if they think
convergence is close.
Threshold relaxation: the threshold the user picked at run start is
binding for Claude. Only the user, in chat, can relax it — and they
have to do so explicitly at an escalation point. Any relaxation is logged
in VERDICT.md so the change of bar is transparent. Don't relax silently
because "we're close."
Goal: prove the loop converged on something real, not on confirmation bias.
Run one full cycle (Phases 1 → 2 → 3) without remediation.
If new findings emerge above the threshold, you didn't actually converge — loop back to Phase 4 and try again. Don't fudge.
If the confirmation pass is clean, write the final verdict to
audit-evidence/VERDICT.md:
# Full UI Experience Audit — VERDICT
App: <name>
Platform: ios | web | fullstack | cross-platform
Mode: solo | team
Threshold: critical-only | critical-high | critical-high-medium | zero-defects
Threshold relaxations during run: <none, or list with timestamps>
Cycles: <N> of <max_cycles>
Final coverage axes: <axis: yes|no|not-supported per row>
## Summary
- Screens audited: <N>
- Interactions validated: <N>
- Backend endpoints validated: <N>
- Findings entered (total across cycles): <N>
- Findings remediated: <N>
- Findings remaining at exit: <N> (all below threshold)
## Per-Cycle History
| Cycle | Entered | Remediated | Open at Exit | Notes |
|-------|---------|------------|--------------|-------|
| 1 | 47 | 41 | 6 | first pass; 4 backend, 2 visual |
| 2 | 14 | 12 | 2 | regressions from cycle-1 fixes |
| 3 | 3 | 3 | 0 | … |
| 4 (clean) | 0 | — | 0 | confirmation pass — no new findings |
## Verdict
PASS | PASS (LIMITED COVERAGE) | FAIL | FAIL (CYCLE-CAP REACHED) | PARTIAL (USER-INTERRUPTED)
## Hand-offs (if any remain)
<list of below-threshold findings, with severity + owner suggestion>
Invoke gate-validation-discipline AND verification-before-completion
on the verdict itself. If you can't cite specific evidence for "PASS",
it's not PASS yet.
Verdict mapping:
| Verdict | When |
|---|---|
| PASS | Threshold met + clean confirmation pass + all coverage axes audited |
| PASS (LIMITED COVERAGE) | Threshold met + clean pass + at least one coverage axis was opted out (no) |
| FAIL | Threshold not met after the loop ran to completion (rare — only happens with explicit user-relaxed threshold contradictions) |
| FAIL (CYCLE-CAP REACHED) | Hit max-cycle cap without converging |
| PARTIAL (USER-INTERRUPTED) | User said stop mid-loop; partial verdict in VERDICT-PARTIAL.md |
This skill is a coordinator. It pulls rigor from skills that already exist rather than reinventing them.
| Concern | Owner skill / file | Phase used in |
|---|---|---|
| Pre-loop environment sanity | preflight | Phase 0 |
| Inventory protocol | full-functional-audit (Phase 1 EXPLORE) | Phase 1 |
| Per-screen UX rigor | ui-experience-audit | Phase 2 |
| Visual depth — multi-state, state-forcing, regression diff, cross-screen consistency | references/visual-experience-audit.md (this skill's depth playbook) | Phase 2 |
| Visual QA per screenshot | visual-inspection | Phase 2 (sub-step) |
| Real-system feature exercise | functional-validation | Phase 3 |
| iOS evidence capture | ios-validation-runner | Phase 3 (iOS) |
| Web automation | agent-browser | Phase 2, 3 (web) |
| Anti-mocking guard | no-mocking-validation-gates | Phase 4 |
| Evidence-cited completion | gate-validation-discipline | Phase 5, 6 |
| Pre-completion behavioral check | verification-before-completion | Phase 6 |
| Comprehensive evidence run | e2e-validate (optional final pass) | Phase 6 |
If a skill in this list isn't installed, this skill still runs — it falls back to the inline instructions in the relevant phase. But the deeper version of every phase lives in the owner skill above.
| Resource | Lock | Held by | Reason |
|---|---|---|---|
iOS simulator (xcrun simctl) | EXCLUSIVE | one agent at a time | concurrent taps corrupt state |
Browser tab (agent-browser) | EXCLUSIVE per tab | one agent at a time per tab | DOM refs go stale on concurrent navigation |
| Backend (singleton) | SHARED | any agent | reads parallelize fine; writes serialize via API contract |
| Code edits to same file | EXCLUSIVE | one agent at a time | merge conflicts |
| Code edits to disjoint modules | PARALLEL | many agents | low collision risk |
| Codebase reads (grep, repomix) | PARALLEL | many agents | read-only |
| Curl on read endpoints | PARALLEL | many agents | idempotent |
| Curl on write endpoints | SERIAL | one agent | state mutation |
| Build / compile | EXCLUSIVE | one agent | shared output dir |
When in doubt, serialize. The cost of a false parallel run (corrupted simulator, half-applied refactor) far exceeds the wall-clock saved.
VERDICT.md.run-config.md): the loop stops there
regardless. A capped-out run produces FAIL (CYCLE-CAP REACHED) with the
full history — still useful output.run-config.md (no, not not-supported), the best the verdict can be
is PASS (LIMITED COVERAGE). Don't upgrade it.VERDICT-PARTIAL.md listing the findings observed so far + which phase
was active when interrupted, and stop. Don't try to "wrap up the
cycle" — the user said stop.| Pattern | Why it's wrong | Do this instead |
|---|---|---|
| Skipping the run-start questions and assuming defaults | The user gets a report calibrated to a threshold they didn't agree to; PASS / FAIL becomes meaningless | Always ask threshold + mode at run start |
| Using Playwright "because functional-validation says so" | Inconsistent with the rest of this user's ecosystem; loses agent-browser's session persistence | Always use agent-browser for web in this skill |
| Looping forever on stuck findings | Wastes context and gives the user nothing actionable | Detect stuck state (same findings 2 cycles), escalate |
| Relaxing the threshold mid-loop "because we're close" | Confirmation bias dressed up as pragmatism | Threshold is binding; if it's wrong, restart with a different threshold |
| Running Phase 4 fixes in parallel without mutex | Corrupted simulator state, half-applied refactors, false FAILs everywhere | Apply the resource mutex matrix; serialize on shared resources |
| "Logging and continuing" past a Phase 3 FAIL | The whole loop is built on Phase 4 actually fixing things; deferral breaks the contract | Fix every finding before Phase 5; that's the deal |
| Skipping the clean confirmation pass | The loop's exit may be a coincidence, not real convergence | Phase 6 is mandatory; one full cycle with zero new findings |
| Marking PASS based on "team validator subagent reported PASS" | Subagents report file existence; you must read content | Invoke gate-validation-discipline and cite specific evidence yourself |
| Solo mode for a 50-screen app | Wall-clock blows out, context exhausts, mistakes accumulate | Recommend team mode whenever screens × interactions > ~50 |
| Team mode for a 3-screen app | Coordination overhead exceeds the parallel speedup; subagents fight over the simulator | Solo mode for small apps |
| Auditing only the happy path | Empty / overflow / error / dark-mode states contain most defects | Declare coverage axes in Phase 0; audit each |
functional-validation directlyui-experience-auditvisual-inspectionfull-functional-audit with
REMEDIATE phase skipped, or e2e-validate --auditworktree-merge-validate, which already
invokes this skill's pieces in its Phase 5e2e-validate (the UX phases
here are wasted effort without a UI surface)full-functional-audit — same DNA on the breadth side, but only does
one remediation pass and lacks the per-screen UX rigor. Use this skill when
you want both UX depth + the looping fix-until-clean behaviour.ui-experience-audit — same DNA on the depth side, but per-screen
only and doesn't fix anything. Use this skill when the audit needs to span
the whole app and remediate as it goes.e2e-validate — overlaps in the validation engine. This skill uses
e2e-validate's patterns and can call it as the final-pass execution
engine in Phase 6, but adds the UX layer + the convergence loop on top.worktree-merge-validate — superset for the merge-then-audit case.
Use that when you have worktrees to land first; use this skill when main
is already consolidated and the audit is the whole job.ui-experience-audit — per-screen UX protocol invoked in Phase 2full-functional-audit — breadth-first inventory + per-interaction validationfunctional-validation — Iron Rule and platform-specific validatione2e-validate — execution engine; optional Phase 6 final passios-validation-runner — iOS evidence capture, used in Phase 3 for iOSagent-browser — canonical web tooling for Phase 2 / 3 / 6visual-inspection — per-screenshot QA invoked from inside Phase 2gate-validation-discipline — evidence-cited completion enforced at every phase exitverification-before-completion — pre-claim discipline for the final verdictno-mocking-validation-gates — invoked whenever Phase 4 feels tempted to mockpreflight — environment sanity check before the loop startsworktree-merge-validate — superset for the consolidate-then-audit casereferences/phase-0-setup.md — detailed Phase 0 templates: run-config.md
block, tool-availability check commands, repomix fallback policy,
coverage-axis semantics. Read on first cycle of every run.references/visual-experience-audit.md — Phase 2 depth playbook:
multi-state capture per element (default/hover/focus/active/disabled/
loading/success/error), screen-variant capture (empty/loading/populated/
overflow/error/first-launch), light+dark+reduced-motion modes, the
cross-screen consistency audit, cross-cycle regression diff, the
static-analysis visual grep playbook for degraded mode, and
state-forcing recipes (the recipes that actually let you reach each
state). Read on first cycle of every run; this is the file that
makes the audit catch visuals as well as experience.references/team-coordination.md — solo vs team execution, subagent
prompts, resource mutex enforcement. Read only if team mode is chosen
AND subagents are available.references/web-protocol.md — agent-browser command sequences for
Phases 2–3 + 6 on web / full-stack projects.references/ios-protocol.md — xcrun simctl + ios-validation-runner
patterns for iOS / cross-platform mobile.references/fix-loop-protocol.md — the diagnose → fix → rebuild →
re-validate algorithm, including the no-mock guard, build-failure
recovery, and stuck-state detection.references/inventory-template.md — the structured format for
cycle-NN/inventory.md, including finding/interaction ID stability rules.assets/cycle-report-template.md — copy-paste template for per-cycle
synthesis. Write your filled report into audit-evidence/cycle-NN/.