Persona Auditor

Persona Auditor（数字人审计员）

1. Positioning & Iron Rules

Positioning: a comprehensive audit-orchestration skill whose goal is precise fixing — find the errors the user would only discover through costly trial-and-error (or never notice at all), collapse them into a handful of root causes, and let the agent fix it right the first time. It is built from four parts:

1. Main line (the differentiator): user personas → project structure map → state-machine exhaustion → two-layer persona traversal → experience-layer three-way alignment → reference group → god's-eye attribution. It hunts the "contradiction between underlying logic and user experience" — built for "stuck on one point across many rounds of fixes, missing the global view".
2. Orchestrated reuse (don't reinvent): for security / AI-smell / over-engineering / store review / general correctness, load and run existing skills and merge their results into one unified report.
3. Self-built checks (not covered by any existing skill):
   • Release hygiene: development trial-and-error, conversations, summary conclusions, real personal information, secrets, and internal decisions written into code / config / comments / docs.
   • Defensive-content pollution: guardrail metadata (corrections, risk warnings, discipline, self-reminders) leaked into public deliverables and user-visible strings.
   • Wheel-reinvention audit: "this whole module has a more mature open-source alternative, but you hand-rolled an outdated one".
   • Adapter-convergence audit (tech-stack unification): "the same concern was solved N times, in N parallel ways, and never converged to one seam" — the subagent/borrowed-tech failure mode that leaves one concern with N adapters (or 1 live + 1 dead), a write-only capability registry, or two names/units for one fact.
   • Publish gate (pre-publication self-check): "my OWN public artifact about to ship carries a specific-project fingerprint" — a project noun, a concrete field name/unit/value, a named borrowed framework, or a producer-voice "we" — applied to the artifact in your hand before it goes out (covers the skill's own README/SKILL/marketing).
4. Adaptive scope: depth tiers (Lite/Standard/Deep) and loop modes (one-shot/incremental/gate) so the audit weight matches the project, never over- or under-auditing.

Paper traversal is the means, not the end: not executing, not clicking is how we cheaply exhaust every user path — faster, more global than real clicking, able to see root causes at a glance. But it is never an excuse to "not fix": the audit's closed loop is report (root cause + precise location) → user confirms → agent fixes precisely → verify via falsifiable check (symptom disappears).

Iron rules (9, not a wall — each one earns its place):

1. Do not execute code, do not really click, do not modify code — mainline work happens on paper.
2. Code is the single source of truth: reason from the real behavior recovered by reading code, not from design docs or memory.
3. Do not fall into the "code self-consistency" trap: internally consistent code ≠ a good product.
4. Exhaustiveness is the soul; sampling is negligence: steps 1.5/2/3 must fully traverse the structure × persona × function × operation × state × timing matrix; many walker subagents each reason independently; only after traversing all paths may you do root-cause analysis. Forbidden to sample one happy path and conclude.
5. Reuse first, don't reinvent: for security / AI-smell / maintainability / review, load llm-sast-scanner / code-auditor / ponytail-audit / code-reviewer; do not rewrite their rules.
6. The self-built checks (release hygiene + defensive pollution + wheel reinvention + adapter convergence + publish gate) are this skill's own — always run them, never skip.
7. Read-the-code verification spans multiple steps, not just once at step 1: walker traversal (step 3), extreme testing (step 4), three-way alignment (step 10), and attribution (step 11) must each re-read the code to verify; forbidden to conclude from step-1 memory. Every file:line must be "just read / just grepped in this round", not "from memory" — memory goes stale and hallucinates.
8. No false positives, no over-auditing: before reporting anything, confirm "does this scenario apply?" — no store review for something not shipping, no mobile App Store review for a desktop app, no treating test fixtures / vendored code / build artifacts / .env templates / doc TODO placeholders as production bugs. And match the audit weight to the scenario — never run the heavy pipeline on a landing page. A wrong report hurts trust more than a missed one.
9. Honest + falsifiable: if you can't find it, say what's missing — never fabricate. Every root-cause conclusion must carry a falsifiable verification method ("if I fix X, symptom Y disappears; if Y persists, X was wrong"); an unfalsifiable statement is an impression, tagged 【impression, no verification path】, never a finding.

2. Methodology (Intake Gate + Steps)

Intake Gate (mandatory, never skip, never guess)

Core principle: the agent answers first, the human only fills what AI can't know. This skill is for the agent itself — it can read code, README, and context. So most questions are answered by the agent first, inferred from code (with evidence + confidence), not dumped on the human. Only what "isn't in code, only in the founder's head" gets asked of the human.

Round 1 — agent self-answers (infer before asking). Read code + README + context; answer each item with inferred answer + evidence + confidence (high / medium / low):

1. Project type — web app / CLI / library / desktop app / agent system / game / other (from README / package.json / structure). This decides what "structure unit" means in Step 1.5.
2. Target users — how many types, what habits (reverse-infer from README / copy / features).
3. Release scenario — ships where? personal vs commercial? software-copyright? (infer from package.json / README / deploy config; decides whether compliance / store-review checks apply).
4. Type-specific follow-ups — web/desktop: which journeys are core, which step loses users, any target platform; CLI/library: target devs, integration scenarios, API constraints; agent system: interaction mode (chat/canvas/voice), automation boundary (what must never auto-run); game: target players, core fun, payment/store plan.
5. Depth tier — Lite / Standard / Deep, with a one-line reason (see "Audit Depth Tiers").
6. Loop mode — one-shot / incremental / gate (see "Embedding in an Existing Loop").

Round 2 — human fills the gaps (only what code can't answer). From Round 1, take the items with low confidence or that change the audit conclusion, and ask the human as multiple-choice — each question shows the agent's inferred answer as the recommended option, a few alternatives, and a "skip — use your inference" option.

Always ask the human (code never contains these):

1. Design intent — for each core feature, what experience did you want the user to get? (code shows what it does, not what it means to achieve). This is also the ruler for gate vs break in Step 3a.
2. Real user thoughts — the actual habits / tolerance / pain points of your target users (not in code).
3. Release final say — does it actually ship / register copyright? (partly inferable, but you decide).
4. Is the requirement itself right? — only when it arises (A/B reference-group choice).

Fallback rule: skipped items use the agent's inferred value, tagged 【agent-inferred, not user-stated, needs confirmation】. If a point arises that "only the user can decide" (A/B reference group, requirement validity, wheel replacement, depth tier, loop mode), stop and ask — never decide for them.

Audit Depth Tiers (adapt the weight to the project)

Not every project needs a heavy audit. The agent infers a tier from the intake answers, recommends it with a reason, and lets the user override.

How to decide: ① project size ② purpose (self-use/internal/commercial/shipping) ③ release scenario ④ risk surface (user data? concurrency? auth/payment? AI mainline?) ⑤ user intent ("quick look" vs "full acceptance").

Rules: recommend, don't decide (state tier + reason, let user override); never silently escalate (a big codebase alone is not a reason for Deep); record the tier honestly in the report header.

Embedding in an Existing Loop

Execution principles: baseline once, then increment (first run builds personas + state machine + root causes; later runs are Incremental and reuse it — never re-run full unless asked or structure changed); incremental scope = git diff + reverse-infer affected paths; gate pass criteria stated up front; match output to the loop (full report is useless mid-loop, bare PASS/FAIL useless pre-release).

Light Research (after intake gate, before step 0; mandatory for Standard/Deep, skippable for Lite)

Personas must not be invented off the top of your head. A round of light research (capped at 3–5 searches) to get three things: ① target-user commonalities ② real pain points ③ behavior patterns. Disciplines: every conclusion carries a source URL; when research conflicts with the user-stated intake answers, user-stated wins (the founder knows their product better than external research), but list the conflict explicitly.

Step 0: Set the ruler — user-persona layering (targeted)

Based on three-way synthesis: intake gate (human-stated) + agent self-answer (code-inferred) + light research (external data), produce:

• User-persona layering table: ≥3 user types; for each: usage habits / expectations / tolerance / features they will and won't use / pain points / behavior patterns. Tag each item's source: 【user-stated】/【agent-inferred】/【light research · URL】.
• Design-intent table: for each feature, "what experience the designer wanted the user to get", source-tagged. This table doubles as the gate list for Step 3a's gate-vs-break distinction.

Step 1: Recover the truth — read code and model the state machine

• Recover the real state machine: state variables (with initial values), transition conditions, branches, boundaries, race points.
• Recover the real behavior of each feature (what the code actually does, not what the docs claim).
• Annotate: deviations between actual code behavior and design intent.

Step 1.5: Project structure map (the "brain" — see the whole before dispatching)

Before exhaustively walking paths, list what this project actually contains — so the walkers are assigned, not left to guess. Read code (not docs alone) and produce:

1. Structure units — what this project is made of, in its own organizing terms (never preseed a term):
   • web app → pages / routes / feature modules
   • CLI → commands / subcommands
   • game → play systems / mechanics
   • agent system → capability scenarios (whatever the project itself calls them)
   • library → modules / API surfaces
2. Core journeys per unit — the typical user task in each unit (1–N journeys each).
3. Journey inventory — one table of all units × their journeys. This is the sole input to Step 2.

Coverage check (explicit): the inventory must state "N units × M journeys; unit A has k journeys, unit B has j…" — a missed unit is a failure, not an option. If the tier is Lite, skip units honestly and say why, don't silently drop them.

Step 2: Exhaust paths — persona combos + combination-reuse principle

Iron rule: exhaustion = fully traversing persona combos × journey × operation × state × timing (where "journey" comes from Step 1.5's inventory), but "combos" use equivalence classes + boundary values + orthogonal arrays, not the full Cartesian product. Forbidden to sample one happy path and conclude.

The no-miss methodology (classic software-testing trio):

1. Equivalence-class partitioning: personas by "behavioral similarity"; journeys grouped by "same kind of behavior" (all "create X" is one class); operations into "normal / abnormal / boundary / interruption" four classes, pick representative values per class.
2. Boundary-value analysis: test both sides of numeric/length/count boundaries (0 and 1, upper and upper+1, empty and 1 char) — bugs cluster at boundaries.
3. Orthogonal arrays: guarantee "every pair of dimensions' combination is covered at least once" for 3+ factors (persona × journey × operation); for 2 factors, full combination.

Coverage must be quantified and provable: the report states covered N personas × M journey groups × K operation classes = P paths; orthogonal table guarantees every two-dimension combination ≥1; boundary values cover 0/1/upper/upper+1.

Persona = persona × scenario combination (not single persona, not full Cartesian product):

1. List single-scenario personas (each persona type × each scenario — use the project's own scenario names).
2. List combined-scenario personas (real users often "do both A and B").
3. Combination-reuse principle (avoids explosion): if "A alone" and "B alone" are each tested fine, the "A+B" persona only tests the cross-scenario delta: ① precise switching: is moving between A↔B precise, reversible, free of leftover wrong state; ② cross-scenario recall: does the memory/state layer know the relation between A and B, and recall correctly without contamination or loss; ③ is the cross-scenario mechanism working at all. Only fully test a combination when a single scenario wasn't tested or the combo introduces new state.

Persona count is justified, not arbitrary: total = needed combos, capped ≤10. Over the cap, prioritize "single-scenario first, then high-value combos", and state what was dropped and why.

Step 3: Two-layer persona traversal — mechanical walker (objective) + intent observer (subjective)

Key distinction: deterministic traversal — code and state machines are deterministic, not a chaotic multi-agent swarm. Split into two layers with different jobs and different output status:

• Layer A — mechanical walker (objective): walks every path, records only facts. Output is falsifiable.
• Layer B — intent observer (subjective, ONE persona): watches Layer A's facts, produces reference opinions. Output tagged 【主观参考, 非可证伪发现】 — a hypothesis generator, not a finding.

3a. Layer A — mechanical walkers (record facts, never judge)

1. Dispatch walkers: one per persona combo from step 2. Prompt synthesized from ① light research ② intake gate ③ code reverse-inference.

2. Each walker verifies along the full code chain and records ONLY four facts per step:

   • reached: which step it reached (read code at each link: user action → entry function → state transition → tool → persistence → output → new state);
   • broke: did it break here — an objective, code-verifiable fact: no way to continue (no available action / state deadlocked / thrown error). Confirm by reading code, tag file:line.
   • gate_or_break: is this stop a gate or a break? A gate = an intended human-in-the-loop pause (from Step 0's design-intent table — e.g. confirm/approve/choose points the user deliberately designed). A break = an unintended stop (no-key early return, infinite hang with no timeout, thrown error). Gates are features, not findings; only breaks are defects. When unsure, tag gate? and let attribution decide with the user.
   • steps: how many steps / rounds before the stop (operation complexity, NOT wall-clock seconds — paper traversal can't measure real time).

3. Forbidden for walkers: do NOT judge "is this a bug / bad UX / would the user be confused" — Layer B / attribution's job. A walker that judges has overstepped; downgrade that to a Layer B hypothesis.

4. Make factual disagreements explicit: if two walkers record differently on the same path (state/persona differs), record both verbatim — a data point, not a dispute to smooth over.

3b. Layer B — intent observer (ONE persona; produces hypotheses, never findings)

Positioning: not "a simulated user", but a human-intent observer — like a senior UX researcher: understands human behavior and product intuition, reads Layer A's factual breakpoints, produces reference opinions.

Input: Layer A's break list (file:line + gate_or_break + step counts).

Output — every item carries three parts + a tag:

【主观参考】关注点: <which break / path segment, anchored to a Layer A fact>
理由: <why a human would most likely care here — behavior / habit intuition>
建议方向: <where attribution should read the code to verify — file:line>

Three disciplines:

1. Every item MUST be tagged 【主观参考, 非可证伪发现】 — iron rule 9: an opinion is not a finding.
2. It may only say "this looks suspicious, suggest reading code X" — never "this is a bug".
3. Its opinion MUST anchor to a Layer A fact ("based on breakpoint #N…") — never free-floating "I think users would be confused".

What the observer adds that walkers can't: prioritization intuition — among many factual breaks, which ones a novice trips on vs an expert ignores, which everyone curses. It reads the facts and adds the human weighting Layer A deliberately does not do.

Aggregation (after both layers)

• Layer A: aggregate breaks — single-user-specific (boundary) vs hit-by-all (systemic); gates are recorded but not treated as defects.
• Layer B: attach hypotheses to the systemic breaks.
• Hand both to Step 11 (god's-eye attribution): Layer A facts = hard evidence; Layer B opinions = investigation leads. Attribution reads code to verify each lead before it becomes a finding. An opinion with no code confirmation stays 【主观参考】, never promoted.

Step 4: Extreme testing — jailbreak/injection + stress/concurrency

• Jailbreak / injection: prompt injection, role hijacking, system impersonation, jailbreak templates, invisible Unicode. Against step 1's "trusted input boundary", find penetration points and correct interception points.
• Multi-task concurrency stress: N tasks simultaneously, races, timeouts, interruption, duplicate submission, rapid switching. Traverse who overwrites whom, whether locks fail, whether queues are serialized.

Step 5: Specialized-check orchestration — reuse existing skills (don't reinvent)

Duplicates go to the more specialized one; dedupe then merge. Before reporting each layer, pass iron rule 8 (false-positive check).

Step 6: Release-hygiene check (self-built, mandatory)

AI-assisted-development-specific — things that should not be publicly released got written into code/config/comments/docs. Scan item by item:

• Real personal information: name / phone / email / address / school / grades / ID number, hardcoded into code, config, fixtures, comments.
• Secrets and credentials: API key / secret / token / private key / personal workspace endpoint, written outside .env.
• Development trial-and-error traces: comments like "incident observed", "user said XX", "audit found XX", "walkthrough gap N", "temporary / do this for now / to delete".
• Internal conversations and conclusions: development-time dialogue, trial-and-error conclusions, internal decisions written into prompts/comments/docs.
• Internal domain information: internal project names, private domains, internal architecture decisions, unpublished account systems.

For each hit, tag 【release hygiene】+ file:line + content category + leak level, and list separately in the report.

Step 7: Defensive-content pollution (self-built, mandatory)

The disease: AI wrote its internal guardrail metadata — corrections, risk warnings, discipline clauses, self-reminders, "as an AI" disclaimers — straight into an artifact meant to be public or a string meant for the end user. The artifact stops being universal: a marketing copy with "⚠️ needs verification" can't be published; open-source code with "// untested, don't trust this" can't be shipped; a user-facing message with "产物自己过一眼" leaks a producer-only concern.

How it differs from release hygiene: release hygiene leaks past dev traces (secrets, PII, trial-and-error); this leaks the current artifact's own defense notes. Same root cause, different symptom — a public deliverable and its internal guardrail metadata were not physically separated.

The three-question test (apply to every suspicious sentence / comment):

1. Meta or content? Is this sentence about the artifact (its correctness / trust / status), or is it the artifact (the actual copy / code / doc)?
2. Who is it addressed to? To the producer ("note to self", "for internal review") — or to the end user?
3. Deletion test (falsifiable): delete it — is the artifact still complete and more universal? If yes, it was internal metadata and must be reported.

Signals to scan for:

• Explicit guard markers: ⚠️ / 【备注】 / 【纪律】 / risk warning / disclaimer / "AI-generated, please verify"
• Self-reminder speech: "as an AI I remind you", "please verify", "not tested", "don't ship", "for reference only", "does not constitute advice"
• Code self-notes: TODO / FIXME / HACK / // note to self / // this broke before, don't touch
• Leaked internal correction: "this was wrong before", "temporary", "for now", "internal wording", "internal decision"

Where to scan — five surfaces (breadth: not just chat and deliverables):

Defensive pollution hides in every user-visible string. Scan all five:

1. Conversation output — appendAssistant / finalText / appendBrief / dialogue messages.
2. Deliverable files — docs / code / config meant to be published or shipped (overlaps release hygiene).
3. Settings / config UI text — model pickers, tier labels, capability maps, degradation-matrix wording, parameter descriptions. Internal architecture terms shown to the user. Locate: displayName / label / title / t(...) in settings components and registry/archive files.
4. Runtime result display — status text, progress, result cards, quality-gate verdicts rendered in the UI. Locate: statusText / progress / verdict rendering.
5. Run log / notifications — notification center, toast, event timeline, log panel. Internal QA/process terms shown to the user as "history". Locate: pushNotification / toast / event feed / log lines that reach the UI.

(The concrete function names above are examples of "how to locate" each surface — the exact names differ per project; use the project's own user-visible-output entry points.)

Rule: a term is internal if it names an architecture component, a process step, or a producer-only concern. The same term is not pollution when the audience is an operator configuring the system (power-user settings may legitimately name engines). Apply iron rule 8: "end-user-facing text" vs "operator-facing text" are different audiences — only the former is pollution.

Severity: High = makes the artifact unpublishable; Medium = local contamination; Low = deliberate compliance disclaimer (flag, don't assume it's a bug).

Root cause (god's-eye): guardrail metadata was not physically separated from the deliverable. Triggers: ① guardrail tools set to on_fail="fix" rewriting in place; ② prompts telling the model to "self-correct" without distinguishing internal vs external; ③ internal discussion leaking into context and copied into output.

Fix direction (for the report, not the audit): two-layer output (draft vs public_release), a product_mode parameter, defense metadata routed to a side channel (logs / review queue) — never injected into the payload. The audit detects the leak and points at its root cause; it does not redesign the pipeline.

Step 8: Wheel-reinvention audit (self-built, mandatory)

Find "this whole module has a more mature open-source alternative, but you hand-rolled an outdated one."

1. Enumerate the project's feature modules / self-built dependencies (especially "looks hand-written": auth, state management, message queue, ORM, template engine, utility collections, protocol implementations…).
2. For each suspected module, search first (web_search / npm view / GitHub search) for mature alternatives, comparing maturity, maintenance, completeness, license.
3. Code comparison: self-built vs mature alternative — where does it fall short?
4. When something is "clearly worse", stop and ask the user whether to replace — don't decide unilaterally.

Step 9: Adapter-convergence audit — tech-stack unification (self-built, mandatory)

The disease this catches is NOT "a module is bad" — it's "the same concern was solved N times, in N parallel ways, and never converged to one seam."

This is the failure mode of subagent / borrowed-tech-driven development: each subagent or borrow adds its own adapter (LLM client, storage layer, renderer, tool dispatcher) for a concern that already had one. Left unmanaged, you get "one concern → N adapters", where N adapter instances each carry lifecycle/params duplicated, or one adapter is dead while a parallel copy is alive. The debt lives in the interface/architecture layer (how many ways reach the same capability), not in whether any single module is well-written.

How it differs from Step 8 (wheel reinvention):

• Wheel reinvention asks "did you hand-roll a worse version of something with a mature OSS alternative?" — the fix is replace/borrow.
• Adapter convergence asks "do you have more than one adapter for the same concern?" — even if each is well-built, having N is the debt. The fix is converge to one seam (delete redundant adapters, or wire the one that's dead, or make N share a single interface).

Detection method — a strict, falsifiable, four-pass scan (per concern):

For each cross-cutting concern (LLM / model, storage / persistence, rendering, tool dispatch, voice I/O, logging, config), run:

1. Enumerate ALL implementations of that concern — find every file that claims the concern's job (grep the concern's verbs: "send"/"openai"/"chat", "write"/"store"/"save", "render"/"draw", "call tool"/"dispatch", "transcribe"/"speak"). Do NOT stop at the one the design doc names; grepping is what surfaces the parallel ones.

2. Find every call-site that reaches the concern — not just the definitions. A definition is separable from whether it's reachable: grep the adapter's exported symbol + import path. A symbol with quotes in a test/script but zero production callers is DEAD (unwired), not "reserved". Record: definition (file:line) + call-sites (count, file:line) + is there a production caller?.

3. Count the distinct adapters (the headline finding): for the same concern, is it 1 adapter used everywhere (converged — good), or N adapters where N≥2, or 1 live + 1 dead, or N that each hold partial capability? The cardinality of "ways to reach a concern" IS the finding.

4. Verify "single source of truth" for the concern's metadata: do the adapters read the SAME capability spec (window size, modalities, dialect, limits), or is the same fact stored in N registries with N field names / N units (e.g. one registry calls it context in tokens, another context in thousands; one uses a boolean supportsImages, another a modalities list containing image)? N registries = drift risk; a value changed in one and stale in the other is the proof. This is the "same fact, two copies" check.

The six signals that flag a convergence failure (each falsifiable, pick matching ones):

Governance method (for the report — how to keep it converged going forward):

• One concern = one seam. For each of the enumerated concerns, name the one adapter that is canonical; every caller must go through it.
• Dead means deleted. An unwired adapter (dead-code signal) is either wired now or removed — never left as "reserved / pilot / test-only". A non-CI script referencing it is not a reason to keep it.
• One metadata registry per concern. Capability facts (context, modalities, dialect, limits) live in exactly one place; the other registries either read it or are merged/deleted. Never two names / two units for one fact.
• Converge, don't keep both. When a concern has 2 live adapters, decide "which is canonical" and migrate — do NOT keep N "because both work". N working adapters is still N× the maintenance.
• Brace against future borrows: the report's conclusion must state "the next time a tech is borrowed, it either enters the canonical seam or is deliberately scoped + removed; nothing stays 'borrowed but unwired'."

Output: list per concern → concern | adapter cardinality (1 / N / 1-live-1-dead) | signal(s) marked | evidence file:line | canonical seam to converge to | action (delete / wire / merge).

Every conclusion obeys iron rule 9: a convergence finding must be falsifiable — "delete the dead adapter → does behavior change? no → it was dead"; "route all callers through the canonical seam → do the N ways collapse to 1? yes → convergence confirmed".

Step 10: Experience-layer three-way alignment + reference group

• Three-way alignment: for each feature, lay out ① design intent ② actual code behavior ③ real user expectation; find the gaps, focusing on "self-consistent but experience-wrong".
• Reference-group experiment: for features where "is the requirement itself right" is doubtful, design A/B comparisons, and on paper traverse what each design gives the user.

Step 11: God's-eye global attribution (the last step — after all errors have arrived)

This is the final attribution of the whole audit — wait until all errors from every prior step (walker traversal + six-layer checks + three-way alignment + stress testing) are collected.

Attribution methodology (distinguish "correlation" from "causation"):

1. Collect the full error set: aggregate all errors into one table (each with file:line + trigger condition + symptom).
2. Cluster candidate root causes: by "shared code location / trigger condition / mechanism". Each cluster is a candidate (not yet verified).
3. Counterfactual verification (separates root cause from symptom): for each candidate — "if I fix this one spot, do the errors in this cluster disappear together?" Disappear together → true root cause; only one disappears → it was a symptom. Write it out: candidate X → assume fixed → traverse: do A/B/C disappear?
4. Draw the causal chain (not a flat list): root cause → intermediate cause → symptom. Mark necessary/sufficient conditions.
5. Layer root causes + rank by impact: prioritize by "how many symptoms one root cause eliminates", not by individual symptom severity.
6. Every root cause carries a falsifiable verification method (mandatory): "how to verify it's true" — assume X is true → fix X → expect A/B/C to disappear together; if they persist, X is wrong. No verification path = tag 【impression, no verification path】, never a conclusion.

Step 12: Produce the report — classified layers + converged directions

Output the layered results + step 11's attribution. The body is the layer classification, but the conclusion is "the few root causes + impact-ranked convergence directions", not a symptom list.

Step 13: Publish gate — self-check BEFORE releasing any public artifact (self-built, mandatory)

The disease: you're about to publish something public — a README, a marketing copy, an open-source skill, a public doc, a released string — but it carries a specific-project fingerprint (your own product's name, an internal borrowed-library name, a concrete field name/unit/value you measured, a "we / our product" voice). It works for you because it's your own context; it leaks because the audience is a stranger.

This is Step 7 (defensive pollution) applied to YOUR OWN artifact you're about to ship, rather than to a codebase you're auditing. Step 7 scans someone else's deliverable; Step 13 scans the one in your hand, right before it goes out.

Trigger: whenever you are about to publish / commit / push / release / submit anything that a stranger will read — a repo file, a README, a skill, a landing page, a public doc, an issue, a PR description. Apply it to the artifact itself, not just to code.

The four-question test (run against every public artifact before releasing):

1. Project-specific noun? Does it name your own product/feature/domain (a brand, an internal module, a scenario name)? → Replace with a generic term (e.g. "a card", "a scene", "an agent workspace").
2. Fingerprint detail? Does it carry a concrete field name, unit, or measured value that only your code produces (a registry field, a XX:1000 number, a hardcoded enum value)? → Abstract to a placeholder (<field>, <value>), or phrase it as "one registry calls it X, another Y" without the real names.
3. Borrowed/inspiration name? Does it name a specific third-party project you borrowed from, as if the reader knows it (a framework's name as a contrast)? → Say the kind instead ("a chaotic multi-agent swarm"), not the brand.
4. Producer-voice leakage? Does it address the producer ("note to self", "we/there's only one dev", "my product") instead of the reader? → Rewrite for the reader; the artifact must stand alone without knowing you.

The deletion test (falsifiable, iron rule 9): delete every project-specific noun / fingerprint / borrowed name / producer-voice phrase — is the artifact still complete and MORE universal? If yes, those were leaks and must go. If removing it breaks the meaning, it was load-bearing; keep it but phrase it generically.

Breadth — apply it everywhere, not just the main file: README, marketing/promotion copy, the skill's own SKILL.md, public docs, example code, config templates, commit messages, PR descriptions, issue bodies, release notes. The leak hides in the small file as often as the big one.

Severity: High = leaks an internal design/product detail that (a) does not apply to strangers, or (b) reveals you measured an internal metric — makes the artifact non-universal; Medium = a named borrowed framework subtly narrowing the audience; Low = a producer-voice "we" that reads oddly but doesn't confuse.

Iron rule 8 (false-positive check): a generic word (rendering, storage, agent, card, scene, model) is NOT a leak — it's the reader-facing vocabulary. Only flag terms that (a) are proper nouns of your own project, (b) are concrete fingerprints, or (c) assume the reader shares your internal context. Don't over-sanitize a good universal sentence.

3. Output Format

# Persona Auditor Report
## 0. Audit tier + scope (which tier ran, what was skipped and why — honest)
## 1. User-persona layering table + design-intent table (source-tagged)
## 2. State-machine recovery + deviations from design intent
## 3. Project structure map (units × journeys inventory; coverage check)
## 4. Exhaustion matrix (persona × journey × operation × state × timing, coverage count)
## 5. Two-layer persona traversal results
     - 5a. Mechanical walker report: factual breaks (reached / broke / gate_or_break / steps / file:line)
     - 5b. Intent observer hypotheses: 【主观参考】opinions anchored to breaks
## 6. Extreme-test results — jailbreak / concurrency
## 7. Specialized-check results (security / AI-smell / compliance / general)
## 8. Release-hygiene check
## 9. Defensive-content pollution (five surfaces)
## 10. Wheel-reinvention audit
## 11. Adapter-convergence audit (tech-stack unification) — per concern: cardinality / signals / evidence / canonical seam / action
## 12. Experience-layer three-way alignment + reference group
## 13. God's-eye global attribution (counterfactually verified root causes)
      - full error set → candidate clustering → counterfactual verification → causal chain → impact ranking
## 14. Convergence directions (by root-cause impact, not symptom severity)

Report header states the audit tier and what was skipped (honest, not hidden). Every defect uniformly carries: `trigger sequence → expected vs act

…(truncated)