v1.9.6 prep: preserve identity-critical facts; ambiguity-aware review and trial

references/intake.md

@@ -87,7 +87,20 @@ clarification — the material sharpens the questions. Run conversationally:
      intent understanding
 4. **Extract** — pull the techniques, constraints, domain specifics, and
    intent from ALL provided material. Multiple sources combine into a
-   best-of-all-worlds understanding.
+   best-of-all-worlds understanding. That synthesis never drops what the
+   package will later need to tell entities apart:
+   - preserve identity-critical relationships (entity ↔ role ↔
+     identifier/alias — machines, accounts, people, products, records,
+     services) when they are material to later decisions or tool targets;
+   - keep explicitly distinct entities/identifiers distinct — do not
+     collapse them into one;
+   - when sources disagree on an identity-critical fact, keep the conflict
+     source-attributed and unresolved rather than synthesizing a single
+     "best" value;
+   - when identity is genuinely ambiguous, preserve the ambiguity instead of
+     silently resolving it.
+   The preserved relationships and conflicts are carried forward in the
+   collected-material summary handed to Pattern.
 5. **Author original** — write the generated package's skill instructions
    fresh from the extraction. Never paste input content verbatim. This is
    the standing practice: extract and incorporate, never copy.

references/skill-anatomy.md

@@ -23,3 +23,10 @@ Engine additions:
 - **Governance artifacts** — every package carries a prompt policy + judge
   rules (helper, advisory, no tool_gate — references/governance.md).
 - **Progressive disclosure** — SKILL.md is the entry point; references load on demand.
+- **Identity placement** — stable, behavior-defining identity facts (who the
+  agent is, which fixed entities it protects) may live in the persona; mutable
+  operational/contextual identity facts (addresses, endpoints, interfaces,
+  contact identifiers, account associations, record IDs) go in
+  references/resources, not the persona. Identity-critical mappings
+  (entity ↔ role ↔ identifiers) are preserved wherever they affect decisions
+  or tool targets; conflicts between sources stay visible until disambiguated.

skills/process-engine-core/references/intake.md

@@ -87,7 +87,20 @@ clarification — the material sharpens the questions. Run conversationally:
      intent understanding
 4. **Extract** — pull the techniques, constraints, domain specifics, and
    intent from ALL provided material. Multiple sources combine into a
-   best-of-all-worlds understanding.
+   best-of-all-worlds understanding. That synthesis never drops what the
+   package will later need to tell entities apart:
+   - preserve identity-critical relationships (entity ↔ role ↔
+     identifier/alias — machines, accounts, people, products, records,
+     services) when they are material to later decisions or tool targets;
+   - keep explicitly distinct entities/identifiers distinct — do not
+     collapse them into one;
+   - when sources disagree on an identity-critical fact, keep the conflict
+     source-attributed and unresolved rather than synthesizing a single
+     "best" value;
+   - when identity is genuinely ambiguous, preserve the ambiguity instead of
+     silently resolving it.
+   The preserved relationships and conflicts are carried forward in the
+   collected-material summary handed to Pattern.
 5. **Author original** — write the generated package's skill instructions
    fresh from the extraction. Never paste input content verbatim. This is
    the standing practice: extract and incorporate, never copy.

skills/process-engine-core/references/skill-anatomy.md

@@ -23,3 +23,10 @@ Engine additions:
 - **Governance artifacts** — every package carries a prompt policy + judge
   rules (helper, advisory, no tool_gate — references/governance.md).
 - **Progressive disclosure** — SKILL.md is the entry point; references load on demand.
+- **Identity placement** — stable, behavior-defining identity facts (who the
+  agent is, which fixed entities it protects) may live in the persona; mutable
+  operational/contextual identity facts (addresses, endpoints, interfaces,
+  contact identifiers, account associations, record IDs) go in
+  references/resources, not the persona. Identity-critical mappings
+  (entity ↔ role ↔ identifiers) are preserved wherever they affect decisions
+  or tool targets; conflicts between sources stay visible until disambiguated.

skills/process-engine-pattern-author/SKILL.md

@@ -67,6 +67,28 @@ handed to review.
    links, text blocks, files, store links, docs — per references/intake.md);
    combine into a best-of-all-worlds design; author ORIGINAL instructions —
    never copy input content verbatim.
+
+   **Preserve identity-critical facts.** When the intent or collected
+   material contains identity-critical relationships — an entity paired with
+   its roles and its identifiers/endpoints/interfaces/aliases (machines,
+   accounts, people, products, records, services) — preserve them in the
+   package wherever they affect decisions or tool targets:
+   - Record the entity ↔ role ↔ identifier mapping explicitly; never flatten
+     distinct identifiers into one, and never infer equivalence the operator
+     did not assert.
+   - Mutable operational/contextual identity facts (addresses, endpoints,
+     interfaces, contact identifiers, account associations, record IDs —
+     anything that can change or varies by context) belong in a package
+     reference/resource by default; genuinely stable, behavior-defining
+     identity (who the agent is, which fixed entities it protects) may live
+     in the persona. Do not bloat the persona with mutable operational
+     facts.
+   - When supplied or live sources disagree on an identity-critical fact,
+     preserve the disagreement, name the sources, and require disambiguating
+     evidence — never silently select one.
+   - If the operator asserts an equivalence (two names are the same entity),
+     record it as an operator-supplied fact; otherwise the generated package
+     must treat identity equivalence as something to prove or leave open.
 5. **Name the evidence** — every technique cites its real source; add to the
    package's evidence library (generated per-package) if new. Bake
    provenance (source URL/date) into each generated SKILL.md metadata when
@@ -107,6 +129,9 @@ handed to review.
 - A SKILL.md whose frontmatter violates the spec (name rules, description
   limits, unknown fields).
 - Draft presented as "done" instead of "draft for review".
+- A generated package that could act on, describe, or gate the WRONG entity
+  because identity-critical facts were dropped, flattened, or silently
+  resolved (e.g., two names/IDs/endpoints collapsed as if equivalent).
 
 ## Verification
 - [ ] Eligibility gate passed — shape decided (project / persona / skill(s) / not an artifact)
@@ -117,6 +142,7 @@ handed to review.
 - [ ] Package folder layout follows the spec (SKILL.md + references/ + optional scripts/assets)
 - [ ] Evidence named for every technique
 - [ ] Safeguard pass done for risk-relevant intents (per-package, sourced)
+- [ ] Identity-critical relationships preserved (entity ↔ role ↔ identifiers) where they affect decisions or tool targets; conflicts kept visible until disambiguated; no silent equivalence inference
 - [ ] Governance artifacts: prompt policy + advisory judge rules (Turnstone-native)
 - [ ] Acceptance criteria written
 - [ ] Marked DRAFT, handed to review

skills/process-engine-review/SKILL.md

@@ -32,7 +32,14 @@ the gate.
 5. **Coverage check**: does the package cover the phases its intent requires
    (references/best-practices.md catalog)?
 6. **Adversarial pass**: try to break it — edge cases, gray zones,
-   rationalizations a user/agent would make.
+   rationalizations a user/agent would make. Include the wrong-entity check:
+   could this package act on, describe, or gate the WRONG entity because
+   names, IDs, roles, endpoints, or aliases are ambiguous (machines,
+   accounts, people, products, records, services)? Ambiguity that could
+   change what the package targets is a REVISE finding: the package must
+   preserve the ambiguity and require disambiguating evidence, or be changed
+   so the target is unambiguous. Do not wave it through as "users will know
+   which one."
 7. **Verdict + evidence**: PASS / REVISE (specific) / REJECT (why). A REVISE
    verdict returns the artifact through the formal fix loop below — never
    straight to ship.
@@ -68,12 +75,15 @@ the gate.
 - A verdict that ignores the safeguard pass for risk-relevant intents.
 - A spec violation waved through ("clients won't notice").
 - "PASS" without evidence.
+- Identity/alias ambiguity waved through when it could make the package
+  act on, describe, or gate the wrong entity.
 
 ## Verification
 - [ ] Standards checklist completed
 - [ ] Spec compliance checked (frontmatter, name/description rules)
 - [ ] Safeguard review completed (risk-relevant intents only)
 - [ ] Coverage check completed against the catalog
 - [ ] Verdict recorded with evidence
+- [ ] Wrong-entity/ambiguity question asked wherever names, IDs, roles, endpoints, or aliases are material to behavior
 - [ ] REVISE loop followed when verdict is REVISE (diagnose → rewrite → audit)
 - [ ] Operator sign-off obtained and logged

skills/process-engine-trial/SKILL.md

@@ -36,6 +36,12 @@ per-package spec.
    Scale case depth to the package: a simple standup-notes skill needs
    2-3 deterministic cases from the acceptance criteria. A risk-relevant
    package needs the full case suite.
+   - identity case (when identity/target selection is material to behavior):
+     include at least one contradiction / alias / near-match case — e.g., two
+     similar names or IDs, a supplied-vs-live source conflict, or a near-miss
+     alias that looks like the target but is not. Record whether the package
+     preserved the distinction (or required disambiguation) instead of
+     collapsing the entities.
 2. **Define fixtures** — setup stubs: model config, persona, skill, scenario
    input. Emit case sets in a structured format (id, prompt, expected_output).
 3. **Run** each case with clean context; record actual vs expected result.
@@ -63,9 +69,12 @@ per-package spec.
 - Trials that only test the happy path.
 - No trigger set for a package with activation-dependent skills.
 - Ignoring a FAIL case ("edge case, won't happen").
+- No contradiction/alias/near-match case for a package whose behavior
+  depends on distinguishing entities (names, IDs, roles, endpoints, aliases).
 
 ## Verification
 - [ ] Cases defined for all acceptance criteria + scope surface
+- [ ] Identity/alias/near-match case included where identity is material to behavior
 - [ ] Trigger set run (where package has activation-dependent skills)
 - [ ] Every case run, actual vs expected recorded
 - [ ] All PASS (or failures routed back to author/review)