Raven pipeline audit follow-ups: scope, staging, @Name → Claude

[DHCross]

Raven Pipeline Audit Review: Scope, Staging, @name → Claude

The audit is a strong, technically precise static analysis of the Raven request pipeline. It maps the flow from dual-channel @Name ingestion through staging, scope, and mode resolution into the Claude prompt builders with unusual clarity for a conversational state machine this complex.

Core architectural bet remains sound:

• @Name / role / vault data determine who the read is about.
• Intent, slash commands, sticky mode, and doctrine determine what kind of read is being produced.
• Prompt builders bind final resolved state to sealed natal, counterpart, synastry, and context profile data.

The architecture is intentionally stateful and deterministic. The remaining risks are mostly friction points where implicit carryover competes with explicit user language.

---

Verified strengths

1. Dual-channel @Name handling is clean

Structured VaultMentionPayload plus text regex fallback merge before scope resolution. The sanitization, dedupe, cap at 6, and re-fetch behavior for staged profiles with incomplete chart data are pragmatic.

Text-only extraction is correctly treated as fallback rather than equal authority.

2. Scope and mode separation is correctly enforced

@Name and role drive resolvedReadScope and staging state.

promptMode is resolved separately through the intent cascade, slash commands, doctrine, and sticky overrides.

Important invariant: a scope change such as @Abby what's asking for attention... can remain in FIELD_REPORT without forcing a mode switch.

3. Staging state machine is deterministic

The S0/S1/S2 staging model and precedence ladder are clear:

• S0_PRIMARY_ONLY
• S1_PRIMARY_PLUS
• S2_SOLO_MIRROR

First-match-wins avoids ambiguous staging mutation.

4. Scope resolution ladder has useful safeguards

The vulnerable-context clarification prompt and structured single-mention → OTHER_SOLO path are good defensive design.

Prior-scope carry-forward and relational continuation preserve dyadic continuity without forcing users to re-mention the same person.

5. Sticky mode enforcement is defense-in-depth

The mode cascade followed by slash > doctrine > sticky overrides is the right priority structure.

The known collision pattern — sticky FIELD_REPORT from ui_button source blocking NEW_SYMBOLIC_READ intent — matches the mechanics described in stickyMode.ts and route.ts:1577-1589.

6. Prompt builders bind data to resolved state

Good isolation and minimal leakage behaviors:

• [NATAL DATA SEAL] tied to active primary from resolved scope
• [STRICT IDENTITY BOUNDARY]
• conditional [COUNTERPART DATA]
• conditional [SYNASTRY GEOMETRY]
• contextProfiles for non-subject mentions
• gated relationalDirection
• gated symbolicMomentDeliveryRubric

---

Highest-priority friction points

1. Sticky mode can override Symbolic Moment intent

shouldReleaseStickyModeForTurn is the intended release valve, especially the symbolicMomentTurnIntent === 'NEW_SYMBOLIC_READ' guard.

However, the ui_button sticky source path can still produce MODE_DRIFT_BLOCKED in cases where the user is clearly asking for a fresh symbolic read.

Tasks

• Refactor shouldReleaseStickyModeForTurn into named predicates.
• Add an explicit decision table in docs.
• Add regression coverage for:
  • sticky FIELD_REPORT
  • source ui_button
  • symbolic-moment phrasing
  • no slash override
  • expected release to new symbolic read

---

2. Staging reducer runs before scope resolution, allowing @Name demotion

When conversationalStagingLocked plus carryover fires, a new structured @mention with role: 'solo_subject' can be reduced to passive contextProfile instead of becoming the active reading subject.

This preserves conversational continuity, but can create a user-visible mismatch: “why didn’t my @mention take?”

Tasks

• Decide whether structured solo_subject should pierce carryover staging locks.
• If not, expose current staging/scope state visibly in debug output or /status.
• Add test coverage for structured solo-subject mention during locked carryover state.

---

3. S2 solo mirror first-person release is fragile

The first-person release heuristic correctly treats language such as “I feel…” as intent to return to anchor.

But mixed phrases can be misread:

• “I wonder about @x’s transits”
• “What is active for @name right now?”
• “I’m curious what @name is carrying today”

These contain first-person framing while the target is clearly third-party.

Tasks

• Strengthen first-person release logic with a secondary check for explicit target name plus curious/possessive verbs.
• Consider requiring an explicit scope pin phrase for ambiguous releases.
• Add regression tests for OTHER_SOLO plus first-person curiosity about the third party.

---

4. Text @Name regex is functional but narrow

Current regex:

/@([a-zA-Z]+(?:[\s'\-.][a-zA-Z]+){0,3})/g

Issues:

• misses some Unicode names
• may miss longer hyphenated/apostrophe names
• can false-positive inside URLs or markdown/code contexts
• Western-name assumptions are baked in

Tasks

• Add safer boundaries.
• Consider Unicode letter matching with \p{L} and u flag.
• Add negative checks for inline code / code fences / URLs.
• Normalize title-case only after matching, not during detection.

---

5. Conversational locks are powerful but opaque

conversationalScopeLocked and conversationalStagingLocked make text cues inert while allowing structured payloads through.

This is deterministic, but not obvious to users or maintainers.

Tasks

Expose a machine-readable “current conversation model state” packet:

type RavenConversationModelState = {
  resolvedScopeKind: string;
  stagingState: 'S0_PRIMARY_ONLY' | 'S1_PRIMARY_PLUS' | 'S2_SOLO_MIRROR';
  activePrimaryId?: string;
  activeCounterpartId?: string;
  contextProfileIds: string[];
  promptMode: string;
  stickyMode?: string;
  stickyModeSource?: string;
  conversationalScopeLocked: boolean;
  conversationalStagingLocked: boolean;
  releaseReason?: string;
  blockingReason?: string;
};

Use this for logs, debug footer, /status, and later Sherlog / Coherence Engine observability.

---

Additional coverage gaps

Not defects, but good future audit passes:

• vault fetch failure for @mention
• partial chart data fallback
• Claude rate-limit / prompt builder failure paths
• transition logging with turn ID, prior state, trigger cue, and final state
• performance of synastry geometry on polyadic turns
• persistence / TTL model for continuous thread, prior scope, and prior staging
• focused diagram or decision table for late mode/sticky resolution

---

Recommended immediate action order

1. Add targeted sticky + NEW_SYMBOLIC_READ release tests.
2. Harden or document first-person release heuristic for OTHER_SOLO.
3. Expose current pipeline state: scope, staging, mode, sticky source, locks.
4. Improve text @Name regex and add false-positive guards.
5. Create a living spec artifact: Raven Conversation Model.

---

Suggested regression matrix

Collision class 1

Sticky FIELD_REPORT from UI + new symbolic request:

• prior mode: FIELD_REPORT
• sticky source: ui_button
• user asks: “give me the symbolic moment now”
• no slash override
• expected: sticky releases; fresh symbolic read starts

Collision class 2

Carryover staging + structured solo-subject mention:

• prior state: relational or staged carryover
• lock: conversationalStagingLocked = true
• input includes structured @Name with role: 'solo_subject'
• expected behavior should be explicitly decided and tested

Collision class 3

OTHER_SOLO + first-person curiosity about third party:

• prior scope: OTHER_SOLO
• user says: “I wonder what @name is carrying today”
• expected: do not release back to anchor merely because of first person

---

Verdict

The pipeline is already close to a coherent, self-diagnosing conversational engine. The complexity is intentional and justified by the need for continuity-preserving symbolic reads.

The weak point is not the architecture itself. It is explainability at the collision points where sticky mode, staging carryover, locks, and explicit new user signals compete.

Targeted tests plus better state observability should make the wrong-person / wrong-mode failures rarer and much easier to diagnose.

[DHCross]

Response to Raven Pipeline Hardening Plan

This is the right direction. Approved with a few important corrections before implementation.

1. Sticky mode release

Yes: refactor shouldReleaseStickyModeForTurn into named predicates and add the fresh structured-read release path.

The key rule should be:

A confirmed NEW_SYMBOLIC_READ should be allowed to break a conflicting sticky mode when the inferred attempted mode is different from the sticky active mode.

Do not make this a loose “any symbolic language releases sticky mode” rule. It should require the classifier to say NEW_SYMBOLIC_READ, not merely detect vague symbolic phrasing.

Expected case:

stickyActiveMode = 'FIELD_REPORT'
stickySource = 'ui_button'
symbolicMomentTurnIntent = 'NEW_SYMBOLIC_READ'
attemptedMode = 'SHARED_SYMBOLIC_MOMENT'

Expected result: release sticky mode and allow drift to SHARED_SYMBOLIC_MOMENT.

Also keep the old defense against casual follow-ups. A user saying “what does that mean?” after a committed read should not accidentally release sticky mode.

2. OTHER_SOLO first-person release

Yes, harden this. The current first-person release heuristic is too blunt.

Preferred behavior:

• First-person alone can release back to anchor.
• First-person plus explicit third-party target should not release.
• Explicit anchor language should release.

Examples:

“I feel off today.”

Likely anchor return.

“I wonder what is active for @Abby today.”

Stay on Abby.

“What about me?”
“Back to my chart.”
“For me now.”

Release to anchor.

This is cleaner than trying to infer every curious verb. Use a clear precedence rule:

1. explicit anchor cue wins anchor release
2. explicit third-party mention/name wins continued OTHER_SOLO
3. otherwise first-person can release

3. Pipeline state exposure

Use a dedicated machine-readable SSE frame, not systemNotice.

Recommendation:

PIPELINE_STATE: { ...json }

or, if the SSE system already standardizes events:

{
  "type": "pipeline_state",
  "payload": { ... }
}

Do not inject this into user-facing prose. This is observability, not Raven voice.

Minimum payload:

type RavenPipelineStateFrame = {
  promptMode: string;
  attemptedMode?: string;
  stickyActiveMode?: string | null;
  stickySource?: string | null;
  stickyReleased: boolean;
  stickyReleaseReason?: string | null;

  resolvedReadScopeKind: string;
  stagingState: 'S0_PRIMARY_ONLY' | 'S1_PRIMARY_PLUS' | 'S2_SOLO_MIRROR';

  activePrimaryId?: string | null;
  activeCounterpartId?: string | null;
  contextProfileIds: string[];

  conversationalScopeLocked: boolean;
  conversationalStagingLocked: boolean;

  symbolicMomentTurnIntent?: string | null;
  scopeDecisionReason?: string | null;
  stagingDecisionReason?: string | null;
};

This frame should be captured by the flight recorder. Later it can power /status, debug footers, and Sherlog analysis.

4. Text @Name regex

Yes, improve it — but do not use the proposed regex as written.

This part is risky:

(?<!`[^`]*)

JavaScript lookbehind cannot safely use variable-length patterns like that. Even where lookbehind support exists, this is not a robust way to ignore inline code or code fences.

Better approach:

1. Pre-strip or mask code fences, inline code, and URLs.
2. Run the mention regex against the sanitized text.
3. Map or report the cleaned matches.

Suggested rough direction:

const sanitized = maskInlineCodeAndUrls(rawText);
const mentionRegex = /(^|[^\w.])@([\p{L}][\p{L}'\-.]*(?:\s+[\p{L}][\p{L}'\-.]*){0,3})(?![\w.-]*\.[\w.-])/gu;

Important: keep structured VaultMentionPayload authoritative. Text regex remains fallback only.

Tests should cover:

@Abby
@Mary-Jane
@O'Connor
@Jean Luc Picard
`@code`
```ts
@code

user@example.com
https://example.com/@handle
normal lowercase @handle if not a vault name

If the product only supports vault names, the final safety check should not be regex cleverness alone. It should be: “does this parsed candidate resolve to a known vault profile?”

### Verification additions

Keep the proposed test plan, but add these exact assertions:

- sticky `FIELD_REPORT` from `ui_button` + `NEW_SYMBOLIC_READ` + `SHARED_SYMBOLIC_MOMENT` releases
- sticky `FIELD_REPORT` + casual follow-up does not release
- `OTHER_SOLO` + “I wonder what is going on with @Abby” stays `OTHER_SOLO`
- `OTHER_SOLO` + “back to me” releases to anchor
- inline/code/URL/email `@` strings are ignored by text mention fallback
- structured `VaultMentionPayload` still works even if text fallback finds nothing

### Open question answer

Use a dedicated `PIPELINE_STATE` frame. Do not put this in `systemNotice`. Do not pollute user-facing metadata unless the UI is explicitly in debug mode.

The machine state should be observable by development tooling first. User-facing surfacing can come later as `/status` or a small debug footer.

### Bottom line

Proceed, but implement this as a hardening pass, not a behavior rewrite. The architecture is already good. The goal is to make state collisions explicit, testable, and visible when debugging — not to make the resolver more permissive or magical.