@elevasis/sdk 1.14.1 → 1.15.1

package/reference/claude-config/rules/vibe.md

@@ -1,208 +1,208 @@
----
-description: Ambient intent classifier -- routes natural-language input to 7 intent buckets without a slash command; Codify and Toggle delegate to /configure
-paths:
-  - "**/*"
----
-
-# Vibe Layer
-
-Vibe is an **ambient, always-on** intent classifier. It activates automatically whenever the user speaks in plain language -- no slash command, no activation phrase, no special syntax. Every natural-language message passes through vibe classification before the agent acts.
-
-This rule applies to all sessions inside external projects. It does NOT apply in the monorepo (ambient routing is off there by default).
-
-## What Vibe Is
-
-Vibe is the translation layer between the user's natural language and the correct agent action. The user describes reality -- "we track deals by Shopify platform", "I'm stuck on this task", "what should I work on next" -- and vibe determines which of the seven intent types the message represents. The agent then routes to the right behavior without the user ever knowing the classification happened.
-
-Vibe coders (non-technical builders) are the primary audience. They build by describing. They never memorize commands, IDs, or schema. The ambient layer closes the gap between what they say and what the system can act on.
-
-## The Seven Intent Types
-
-### 1. Capture
-
-The user wants to record something new -- a task, a note, a piece of information that should persist.
-
-**Recognize by:** action verbs like "add", "create", "remember", "track", "log", "note down", "write down", combined with a thing to record.
-
-**Fixture examples:**
-
-| Input                                             | Why it's Capture                            |
-| ------------------------------------------------- | ------------------------------------------- |
-| "Add a task to follow up with the Shopify client" | Explicit "add a task" with a described item |
-| "Remember to run the campaign report on Friday"   | "Remember to" signals something to persist  |
-| "Track this conversation as a deal note"          | Explicit "track" with a described artifact  |
-
-**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands. Never write without confirmation.
-
-### 2. Query
-
-The user wants to know something about current state -- task priorities, what is pending, what is running, what failed.
-
-**Recognize by:** questions about the current list, status, or queue of things. Includes both static-model queries ("what features are on?") and runtime-entity queries ("what's pending in the queue?"). Route Query to static-model sources (org model, features config) or runtime sources (operations domain) based on the referenced entity.
-
-**Fixture examples:**
-
-| Input                                         | Why it's Query                              |
-| --------------------------------------------- | ------------------------------------------- |
-| "What should I work on next?"                 | Asking for prioritized task list            |
-| "What's pending in the HITL queue?"           | Runtime-entity query about operations state |
-| "What features are enabled for this project?" | Static-model query about features config    |
-
-**Agent action:** read the relevant source (org model, `prj_tasks`, operations domain as available) and narrate the answer in plain language. No writes.
-
-### 3. Describe
-
-The user wants the agent to explain something -- a scope, an entity, a concept within the project.
-
-**Recognize by:** "what is", "what does", "tell me about", "explain", "where am I", "what's going on", "describe", "show me" without an action intent attached.
-
-**Fixture examples:**
-
-| Input                                      | Why it's Describe                                     |
-| ------------------------------------------ | ----------------------------------------------------- |
-| "What's going on with the ZentaraHQ deal?" | Asking for a plain-language description of an entity  |
-| "Tell me about the CRM feature"            | Asking the agent to narrate what a model element does |
-| "Where am I in this project?"              | Asking for current scope narration                    |
-
-**Agent action:** read the relevant org-model label, entity, or scope. Narrate in plain language using label fields from the model -- never invent vocabulary not present in the model. Phase-1 scope covers Model, Features, and Foundations layers only.
-
-### 4. Transition
-
-The user wants to change the status of a task or entity.
-
-**Recognize by:** single-word or short-phrase state signals -- "done", "finished", "complete", "blocked", "stuck", "waiting", "in review", "cancelled" -- applied to a current task or named entity.
-
-**Fixture examples:**
-
-| Input                                         | Why it's Transition                         |
-| --------------------------------------------- | ------------------------------------------- |
-| "Done with the proposal draft"                | "Done" + named artifact = status transition |
-| "Stuck -- blocked waiting on client feedback" | "Stuck" + reason = blocked transition       |
-| "Mark the onboarding task as complete"        | Explicit status-change vocabulary           |
-
-**Agent action:** identify the task or entity being transitioned, confirm the new status with the user, then apply the transition via `elevasis-sdk project:task:save` or equivalent. Never auto-transition without confirmation if the target entity is ambiguous.
-
-### 5. Navigate
-
-The user wants to shift focus -- to a different task, project, feature, or layer of the model.
-
-**Recognize by:** focus-shift vocabulary -- "focus on", "let's look at", "switch to", "back to", "move to", "open", "go to" -- followed by a scope target.
-
-**Fixture examples:**
-
-| Input                                        | Why it's Navigate                                   |
-| -------------------------------------------- | --------------------------------------------------- |
-| "Let's focus on the onboarding flow for now" | "Focus on" + scope target                           |
-| "Switch to the Shopify integration project"  | "Switch to" = navigate to a different project scope |
-| "Back to the CRM tasks"                      | "Back to" = return to a prior scope                 |
-
-**Agent action:** update the active scope in `prj_tasks.resume_context` (current project + task pointer), then narrate the new scope in plain language so the user knows where they are.
-
-### 6. Codify
-
-The user describes organizational reality that is not yet expressed in the model -- industry type, entity kinds, custom attributes, renamed stages, domain vocabulary.
-
-**Recognize by:** declarative "we are" / "we use" / "we track" statements, repeated attribute mentions (second time the same attribute appears), or explicit "add a type / add a field / model X as Y" requests.
-
-**Fixture examples:**
-
-| Input                                                                            | Why it's Codify                                          |
-| -------------------------------------------------------------------------------- | -------------------------------------------------------- |
-| "We're an e-commerce company -- all our deals come from Shopify or Amazon"       | Declares industry + platform attributes not yet in model |
-| "We track deal stage as discovery, scoping, proposal, closed"                    | Describes custom CRM stages that should replace defaults |
-| "Add a project type called 'retainer' with monthly billing and a contract field" | Explicit request to add a new entity extension           |
-
-**Agent action:** delegate immediately to `/configure`. Do not attempt the ceremony yourself. Invoke with the relevant domain: `/configure crm` for deal/contact changes, `/configure projects` for project types, `/configure features` for feature toggles. Plain-language summary of what was detected is acceptable before delegating, but the actual draft-confirm-write ceremony belongs to `/configure`.
-
-This routing applies to both codify levels (decision #21 -- Codify ceremony delegated to `/configure`):
-
-- **Level A** (config-only edits to `organization-model.ts`, feature toggles, label renames): delegate to `/configure <domain>` immediately.
-- **Level B** (new Zod extension files in `foundations/config/extensions/`): also delegate to `/configure <domain>`; `/configure` gates Level B to explicit user asks before scaffolding a new TS file.
-
-Vibe detects the intent and delegates in both cases. It does not run either pipeline itself.
-
-For "build/extend the CRM" asks, classify the structural org-model portion as Codify, then read `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md` before editing. CRM work often spans org-model sales semantics, shared UI routes, hooks, workflow adapters, and deal actions; do not reduce it to only `sales` config or only UI.
-
-For "build/extend lead gen" / "campaign creator" / "outbound list state" asks, classify the structural org-model portion as Codify, then read `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` before editing. Lead-gen work often spans org-model prospecting semantics, shared UI routes, hooks, list/member state, artifacts, touchpoints, and workflow adapters; do not reduce it to only `prospecting` config or only UI.
-
-For "add a custom CRM action" / "Send Quote button" asks, classify as Codify, then read `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before editing. Start with the shared `crmActions` provider path for action visibility, labels, ordering, and render-time configuration. In v1, platform-known/default action endpoint behavior is server-constrained; use project-owned UI that calls the workflow directly when a custom key sits outside that server-dispatched set.
-
-Heuristics for when to propose codification (passed to `/configure` as context):
-
-- First mention of a new attribute: note to `resume_context`, do not propose yet
-- Second mention OR explicit declaration ("we're ecom"): propose extension
-- Explicit ask ("track ecom deals separately"): propose immediately with fuller scope
-- Attribute appearing across 3+ tasks: propose adding field to existing extension
-
-### 7. Toggle
-
-The user wants to enable or disable a feature.
-
-**Recognize by:** feature-control vocabulary -- "turn on", "enable", "disable", "turn off", "activate", "deactivate" -- followed by a feature name or description.
-
-**Fixture examples:**
-
-| Input                           | Why it's Toggle                               |
-| ------------------------------- | --------------------------------------------- |
-| "Turn on the lead-gen feature"  | Explicit "turn on" + feature name             |
-| "Disable monitoring for now"    | "Disable" + feature reference                 |
-| "We don't use SEO, turn it off" | Declarative + "turn it off" = feature disable |
-
-**Agent action:** delegate to `/configure features`. The ceremony (confirm + edit `foundations/config/organization-model.ts` + typecheck) belongs to `/configure`, not to the ambient rule.
-
-## Quick Reference Table
-
-| Intent     | Trigger signal                                                  | Routed to                                  |
-| ---------- | --------------------------------------------------------------- | ------------------------------------------ |
-| Capture    | "add", "remember", "track", "log" + a thing                     | Agent -- draft + confirm + `project:*` CLI |
-| Query      | "what's next", "what's pending", "what failed", "what features" | Agent -- read + narrate                    |
-| Describe   | "what is", "tell me about", "explain", "where am I"             | Agent -- narrate from org model labels     |
-| Transition | "done", "stuck", "blocked", "finished", "complete"              | Agent -- confirm + `project:task:save`     |
-| Navigate   | "focus on", "switch to", "back to", "look at"                   | Agent -- update scope + narrate            |
-| Codify     | "we are X", "we track Y", repeated attribute, "add type/field"  | Delegate to `/configure \<domain>`         |
-| Toggle     | "enable", "disable", "turn on/off" + feature                    | Delegate to `/configure features`          |
-
-## Source of Truth for Plain Language
-
-All plain-language labels come from the OrganizationModel itself -- never from hardcoded strings in this rule file. Every status, entity kind, and layer name in the model carries an inline `label` field (e.g., `{ id: 'revision_requested', label: 'changes needed', semanticClass: 'blocked' }`). When narrating state or confirming an action, read the label from the model and use it verbatim. Do not invent synonyms or fallback vocabulary.
-
-The unified manifest (delivered via `@elevasis/core/organization-model`) is the canonical vocabulary surface. Vibe classifies against it -- capabilities, features, statuses, operations entities, and resource kinds are all discoverable from the manifest without hardcoding.
-
-## Ambiguous Intent
-
-When the user's input does not clearly map to one of the seven types, ask one clarifying question. Do not guess. Do not apply a precedence rule. Do not route to the "closest" intent.
-
-Format: a single neutral question that presents the two (or three) plausible intents as options and asks which the user means.
-
-Example: "That could be a note to capture or a status update on the current task -- which did you mean?"
-
-Never ask more than one question per ambiguous input. If the user's reply is still ambiguous, ask once more, then surface the options explicitly.
-
-## Classifier Threshold
-
-Default threshold: `balanced`.
-
-The threshold controls how aggressively the classifier proposes codification from ambiguous signals:
-
-- `strict` -- only explicit declarations or repeat mentions trigger codify proposals
-- `balanced` -- second mention OR explicit declaration triggers; default
-- `loose` -- first strong signal triggers a proposal
-
-Override per project in `foundations/config/organization-model.ts` under `vibe.classifierThreshold`. The override is merge-aware (Tier 2 sync) and will not be overwritten by template sync operations.
-
-## Phase-1 Scope
-
-This rule covers Phase 1 of the vibe layer rollout. The layers the ambient classifier can narrate and codify in Phase 1 are:
-
-- Layer 1 (Model): narrate schema shape, propose codification edits via `/configure`
-- Layer 4 (Features): describe which features are on/off, propose enabling one via `/configure`
-- Layer 7 (Foundations): explain and edit `organization-model.ts` and `extensions/` via `/configure`
-
-Layers 2 (Public API), 3 (UI Shell Runtime), 5 (Toolkit), and 6 (Graph) require runtime read APIs that are not yet available. Do not attempt to narrate or classify against those layers in Phase 1. If the user's input clearly references one of those layers, acknowledge the scope and explain that full support arrives in a later phase.
-
-## What Vibe Is Not
-
-- Vibe is not a slash command. There is no `/vibe` invocation (decision #19 -- ambient rule, not a skill or command).
-- Vibe is not a skill. It lives in this rule file + CLAUDE.md + the PreToolUse hook -- not in `.claude/skills/`.
-- Vibe does not own the codify ceremony. `/configure` owns draft, confirm, write, and typecheck for both Level A and Level B codify pipelines (decision #21 -- Codify ceremony delegated to `/configure`). Vibe detects intent and hands off.
-- Vibe is not active in the monorepo. If working inside the monorepo (not an `external/` project), this ambient routing does not apply.
+---
+description: Ambient intent classifier -- routes natural-language input to 7 intent buckets without a slash command; Codify and Toggle delegate to /configure
+paths:
+  - "**/*"
+---
+
+# Vibe Layer
+
+Vibe is an **ambient, always-on** intent classifier. It activates automatically whenever the user speaks in plain language -- no slash command, no activation phrase, no special syntax. Every natural-language message passes through vibe classification before the agent acts.
+
+This rule applies to all sessions inside external projects. It does NOT apply in the monorepo (ambient routing is off there by default).
+
+## What Vibe Is
+
+Vibe is the translation layer between the user's natural language and the correct agent action. The user describes reality -- "we track deals by Shopify platform", "I'm stuck on this task", "what should I work on next" -- and vibe determines which of the seven intent types the message represents. The agent then routes to the right behavior without the user ever knowing the classification happened.
+
+Vibe coders (non-technical builders) are the primary audience. They build by describing. They never memorize commands, IDs, or schema. The ambient layer closes the gap between what they say and what the system can act on.
+
+## The Seven Intent Types
+
+### 1. Capture
+
+The user wants to record something new -- a task, a note, a piece of information that should persist.
+
+**Recognize by:** action verbs like "add", "create", "remember", "track", "log", "note down", "write down", combined with a thing to record.
+
+**Fixture examples:**
+
+| Input                                             | Why it's Capture                            |
+| ------------------------------------------------- | ------------------------------------------- |
+| "Add a task to follow up with the Shopify client" | Explicit "add a task" with a described item |
+| "Remember to run the campaign report on Friday"   | "Remember to" signals something to persist  |
+| "Track this conversation as a deal note"          | Explicit "track" with a described artifact  |
+
+**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands. Never write without confirmation.
+
+### 2. Query
+
+The user wants to know something about current state -- task priorities, what is pending, what is running, what failed.
+
+**Recognize by:** questions about the current list, status, or queue of things. Includes both static-model queries ("what features are on?") and runtime-entity queries ("what's pending in the queue?"). Route Query to static-model sources (org model, features config) or runtime sources (operations domain) based on the referenced entity.
+
+**Fixture examples:**
+
+| Input                                         | Why it's Query                              |
+| --------------------------------------------- | ------------------------------------------- |
+| "What should I work on next?"                 | Asking for prioritized task list            |
+| "What's pending in the HITL queue?"           | Runtime-entity query about operations state |
+| "What features are enabled for this project?" | Static-model query about features config    |
+
+**Agent action:** read the relevant source (org model, `prj_tasks`, operations domain as available) and narrate the answer in plain language. No writes.
+
+### 3. Describe
+
+The user wants the agent to explain something -- a scope, an entity, a concept within the project.
+
+**Recognize by:** "what is", "what does", "tell me about", "explain", "where am I", "what's going on", "describe", "show me" without an action intent attached.
+
+**Fixture examples:**
+
+| Input                                      | Why it's Describe                                     |
+| ------------------------------------------ | ----------------------------------------------------- |
+| "What's going on with the ZentaraHQ deal?" | Asking for a plain-language description of an entity  |
+| "Tell me about the CRM feature"            | Asking the agent to narrate what a model element does |
+| "Where am I in this project?"              | Asking for current scope narration                    |
+
+**Agent action:** read the relevant org-model label, entity, or scope. Narrate in plain language using label fields from the model -- never invent vocabulary not present in the model. Phase-1 scope covers Model, Features, and Foundations layers only.
+
+### 4. Transition
+
+The user wants to change the status of a task or entity.
+
+**Recognize by:** single-word or short-phrase state signals -- "done", "finished", "complete", "blocked", "stuck", "waiting", "in review", "cancelled" -- applied to a current task or named entity.
+
+**Fixture examples:**
+
+| Input                                         | Why it's Transition                         |
+| --------------------------------------------- | ------------------------------------------- |
+| "Done with the proposal draft"                | "Done" + named artifact = status transition |
+| "Stuck -- blocked waiting on client feedback" | "Stuck" + reason = blocked transition       |
+| "Mark the onboarding task as complete"        | Explicit status-change vocabulary           |
+
+**Agent action:** identify the task or entity being transitioned, confirm the new status with the user, then apply the transition via `elevasis-sdk project:task:save` or equivalent. Never auto-transition without confirmation if the target entity is ambiguous.
+
+### 5. Navigate
+
+The user wants to shift focus -- to a different task, project, feature, or layer of the model.
+
+**Recognize by:** focus-shift vocabulary -- "focus on", "let's look at", "switch to", "back to", "move to", "open", "go to" -- followed by a scope target.
+
+**Fixture examples:**
+
+| Input                                        | Why it's Navigate                                   |
+| -------------------------------------------- | --------------------------------------------------- |
+| "Let's focus on the onboarding flow for now" | "Focus on" + scope target                           |
+| "Switch to the Shopify integration project"  | "Switch to" = navigate to a different project scope |
+| "Back to the CRM tasks"                      | "Back to" = return to a prior scope                 |
+
+**Agent action:** update the active scope in `prj_tasks.resume_context` (current project + task pointer), then narrate the new scope in plain language so the user knows where they are.
+
+### 6. Codify
+
+The user describes organizational reality that is not yet expressed in the model -- industry type, entity kinds, custom attributes, renamed stages, domain vocabulary.
+
+**Recognize by:** declarative "we are" / "we use" / "we track" statements, repeated attribute mentions (second time the same attribute appears), or explicit "add a type / add a field / model X as Y" requests.
+
+**Fixture examples:**
+
+| Input                                                                            | Why it's Codify                                          |
+| -------------------------------------------------------------------------------- | -------------------------------------------------------- |
+| "We're an e-commerce company -- all our deals come from Shopify or Amazon"       | Declares industry + platform attributes not yet in model |
+| "We track deal stage as discovery, scoping, proposal, closed"                    | Describes custom CRM stages that should replace defaults |
+| "Add a project type called 'retainer' with monthly billing and a contract field" | Explicit request to add a new entity extension           |
+
+**Agent action:** delegate immediately to `/configure`. Do not attempt the ceremony yourself. Invoke with the relevant domain: `/configure crm` for deal/contact changes, `/configure projects` for project types, `/configure features` for feature toggles. Plain-language summary of what was detected is acceptable before delegating, but the actual draft-confirm-write ceremony belongs to `/configure`.
+
+This routing applies to both codify levels (decision #21 -- Codify ceremony delegated to `/configure`):
+
+- **Level A** (config-only edits to `organization-model.ts`, feature toggles, label renames): delegate to `/configure <domain>` immediately.
+- **Level B** (new Zod extension files in `foundations/config/extensions/`): also delegate to `/configure <domain>`; `/configure` gates Level B to explicit user asks before scaffolding a new TS file.
+
+Vibe detects the intent and delegates in both cases. It does not run either pipeline itself.
+
+For "build/extend the CRM" asks, classify the structural org-model portion as Codify, then read `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md` before editing. CRM work often spans org-model sales semantics, shared UI routes, hooks, workflow adapters, and deal actions; do not reduce it to only `sales` config or only UI.
+
+For "build/extend lead gen" / "campaign creator" / "outbound list state" asks, classify the structural org-model portion as Codify, then read `node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` before editing. Lead-gen work often spans org-model prospecting semantics, shared UI routes, hooks, list/member state, artifacts, and workflow adapters; do not reduce it to only `prospecting` config or only UI.
+
+For "add a custom CRM action" / "Send Quote button" asks, classify as Codify, then read `node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before editing. Start with the shared `crmActions` provider path for action visibility, labels, ordering, and render-time configuration. In v1, platform-known/default action endpoint behavior is server-constrained; use project-owned UI that calls the workflow directly when a custom key sits outside that server-dispatched set.
+
+Heuristics for when to propose codification (passed to `/configure` as context):
+
+- First mention of a new attribute: note to `resume_context`, do not propose yet
+- Second mention OR explicit declaration ("we're ecom"): propose extension
+- Explicit ask ("track ecom deals separately"): propose immediately with fuller scope
+- Attribute appearing across 3+ tasks: propose adding field to existing extension
+
+### 7. Toggle
+
+The user wants to enable or disable a feature.
+
+**Recognize by:** feature-control vocabulary -- "turn on", "enable", "disable", "turn off", "activate", "deactivate" -- followed by a feature name or description.
+
+**Fixture examples:**
+
+| Input                           | Why it's Toggle                               |
+| ------------------------------- | --------------------------------------------- |
+| "Turn on the lead-gen feature"  | Explicit "turn on" + feature name             |
+| "Disable monitoring for now"    | "Disable" + feature reference                 |
+| "We don't use SEO, turn it off" | Declarative + "turn it off" = feature disable |
+
+**Agent action:** delegate to `/configure features`. The ceremony (confirm + edit `foundations/config/organization-model.ts` + typecheck) belongs to `/configure`, not to the ambient rule.
+
+## Quick Reference Table
+
+| Intent     | Trigger signal                                                  | Routed to                                  |
+| ---------- | --------------------------------------------------------------- | ------------------------------------------ |
+| Capture    | "add", "remember", "track", "log" + a thing                     | Agent -- draft + confirm + `project:*` CLI |
+| Query      | "what's next", "what's pending", "what failed", "what features" | Agent -- read + narrate                    |
+| Describe   | "what is", "tell me about", "explain", "where am I"             | Agent -- narrate from org model labels     |
+| Transition | "done", "stuck", "blocked", "finished", "complete"              | Agent -- confirm + `project:task:save`     |
+| Navigate   | "focus on", "switch to", "back to", "look at"                   | Agent -- update scope + narrate            |
+| Codify     | "we are X", "we track Y", repeated attribute, "add type/field"  | Delegate to `/configure \<domain>`         |
+| Toggle     | "enable", "disable", "turn on/off" + feature                    | Delegate to `/configure features`          |
+
+## Source of Truth for Plain Language
+
+All plain-language labels come from the OrganizationModel itself -- never from hardcoded strings in this rule file. Every status, entity kind, and layer name in the model carries an inline `label` field (e.g., `{ id: 'revision_requested', label: 'changes needed', semanticClass: 'blocked' }`). When narrating state or confirming an action, read the label from the model and use it verbatim. Do not invent synonyms or fallback vocabulary.
+
+The unified manifest (delivered via `@elevasis/core/organization-model`) is the canonical vocabulary surface. Vibe classifies against it -- capabilities, features, statuses, operations entities, and resource kinds are all discoverable from the manifest without hardcoding.
+
+## Ambiguous Intent
+
+When the user's input does not clearly map to one of the seven types, ask one clarifying question. Do not guess. Do not apply a precedence rule. Do not route to the "closest" intent.
+
+Format: a single neutral question that presents the two (or three) plausible intents as options and asks which the user means.
+
+Example: "That could be a note to capture or a status update on the current task -- which did you mean?"
+
+Never ask more than one question per ambiguous input. If the user's reply is still ambiguous, ask once more, then surface the options explicitly.
+
+## Classifier Threshold
+
+Default threshold: `balanced`.
+
+The threshold controls how aggressively the classifier proposes codification from ambiguous signals:
+
+- `strict` -- only explicit declarations or repeat mentions trigger codify proposals
+- `balanced` -- second mention OR explicit declaration triggers; default
+- `loose` -- first strong signal triggers a proposal
+
+Override per project in `foundations/config/organization-model.ts` under `vibe.classifierThreshold`. The override is merge-aware (Tier 2 sync) and will not be overwritten by template sync operations.
+
+## Phase-1 Scope
+
+This rule covers Phase 1 of the vibe layer rollout. The layers the ambient classifier can narrate and codify in Phase 1 are:
+
+- Layer 1 (Model): narrate schema shape, propose codification edits via `/configure`
+- Layer 4 (Features): describe which features are on/off, propose enabling one via `/configure`
+- Layer 7 (Foundations): explain and edit `organization-model.ts` and `extensions/` via `/configure`
+
+Layers 2 (Public API), 3 (UI Shell Runtime), 5 (Toolkit), and 6 (Graph) require runtime read APIs that are not yet available. Do not attempt to narrate or classify against those layers in Phase 1. If the user's input clearly references one of those layers, acknowledge the scope and explain that full support arrives in a later phase.
+
+## What Vibe Is Not
+
+- Vibe is not a slash command. There is no `/vibe` invocation (decision #19 -- ambient rule, not a skill or command).
+- Vibe is not a skill. It lives in this rule file + CLAUDE.md + the PreToolUse hook -- not in `.claude/skills/`.
+- Vibe does not own the codify ceremony. `/configure` owns draft, confirm, write, and typecheck for both Level A and Level B codify pipelines (decision #21 -- Codify ceremony delegated to `/configure`). Vibe detects intent and hands off.
+- Vibe is not active in the monorepo. If working inside the monorepo (not an `external/` project), this ambient routing does not apply.

package/reference/claude-config/sync-notes/2026-04-27-lead-gen-substrate-train.md

@@ -1,5 +1,7 @@
 # Lead-Gen Substrate Train (Tracks A + B + C)
 
+> **PARTIAL SUPERSEDE — 2026-04-29.** Track A's `acq_touchpoints` table and all `recordTouchpoint` / `listDealTouchpoints` helpers were removed end-to-end on 2026-04-28/29. Replacement substrate for outreach event audit is `acq_deals.activity_log` (JSONB) appended via `acqDb.recordDealActivity`. Replacement substrate for thread context (Instantly thread UUIDs) is the same `activity_log` — `reply_received` entries now carry thread fields in their payload. Ignore every touchpoint-flavored instruction in this note (table creation, hooks, UI tabs, writers, verification). The `acq_artifacts` table and ICP rubric columns from Track A remain valid. Track B + Track C non-touchpoint content remains valid.
+
 ## Why this note exists
 
 This release train ships the Lead-Gen Substrate Generalization across three coordinated tracks:

package/reference/claude-config/sync-notes/2026-04-29-crm-state-and-lead-gen-processing-status.md

@@ -0,0 +1,93 @@
+# CRM State-Change UI + Lead-Gen Processing Status Migration
+
+## Why this note exists
+
+This release train ships two coordinated changes that both flow through the `@elevasis/core` + `@elevasis/ui` + `@elevasis/sdk` package family.
+
+1. **CRM state-change UI + canonical state source.** CRM `state_key` values are now defined canonically in `@elevasis/core/organization-model` as `CRM_PIPELINE_DEFINITION` (mirrors lead-gen's `ACQ_LIST_MEMBERS_LEAD_GEN_PIPELINE` shape). Eight `CRM_*_STATE` constants and a `getValidStatesForStage(definition, stageKey)` helper are exported. The API now exposes `PATCH /api/deals/:dealId/state` with server-side validation against the per-stage allowed-state set, and the deal drawer ships a `StateSelect` plus an Unstaged-deal staging affordance. Manual state changes log `state_changed_manually` (vs. workflow-driven `state_change`).
+
+2. **Lead-gen processing-status migration.** `processing_state` JSONB stage values shift from boolean flags to status strings drawn from `ProcessingStageStatusSchema = 'success' | 'no_result' | 'skipped' | 'error'`. Legacy boolean `true` values continue to read as `success` for the foreseeable future via API normalization. `ListStageProgressSchema` expands from `{ done, total }` to attempted-coverage + per-status counts (`total`, `attempted`, `success`, `noResult`, `skipped`, `error`, `other`, `notAttempted`). Lead-gen list-detail UI renders attempted percentage with stacked status segments. Local `listTool` writers (`updateCompanyStage` / `updateContactStage`) now accept an optional `status` argument; omitted writes default to `success`.
+
+## Applies to
+
+All template-derived projects that:
+
+- consume `@elevasis/core/business/acquisition` types (`ListStageProgressSchema`, `ProcessingStageStatusSchema`, `UpdateCompanyStageParams`, `UpdateContactStageParams`, `TransitionDealStateRequestSchema`)
+- import from `@elevasis/core/organization-model` (the new `CRM_PIPELINE_DEFINITION` + `CRM_*_STATE` constants are exposed for the first time in this release)
+- render the CRM deal drawer or kanban surfaces from `@elevasis/ui` (the drawer now slots `StateSelect` and an Unstaged staging block; `useTransitionState` is a new exported hook)
+- render the lead-gen list-detail progress bars from `@elevasis/ui` (stacked segment rendering replaces single fills)
+- author lead-gen workflows that call `acqDb.updateCompanyStage(...)` / `acqDb.updateContactStage(...)`
+- author CRM workflows that hardcode `state_key` string literals (`discovery_link_sent`, `discovery_replied`, `reply_sent`, `followup_{1,2,3}_sent`, etc.) — these should now import named constants from `@elevasis/core/organization-model`
+
+Operations-only projects with no CRM surface, no `acq_deals` table, and no lead-gen list workflows can ignore this train.
+
+## Required actions
+
+1. Pull template changes with `/git-sync` so the refreshed package baselines (`core/package.json`, `ui/package.json`, `operations/package.json`) and any propagated scaffold doc updates land.
+
+2. After the release train is published, update package versions in the project:
+
+```bash
+pnpm up @elevasis/core @elevasis/ui @elevasis/sdk --latest
+```
+
+3. **Lead-gen workflows** — extend any local `listTool` wrapper signatures to accept the new optional `status` parameter and pass an explicit non-success status where the workflow can distinguish outcomes:
+
+```ts
+updateCompanyStage: (params: {
+  listId: string
+  companyId: string
+  stage: 'extracted'
+  status?: 'success' | 'no_result' | 'skipped' | 'error'
+  executionId?: string
+}) => platform.call({ tool: 'list', method: 'updateCompanyStage', params }) as Promise<void>
+```
+
+Recommended status mapping per stage (`populated`, `extracted`, `discovered`, `verified`, `qualified`, `personalized`, `uploaded`) is documented in `apps/docs/content/docs/in-progress/active-development/sdk-changes/ship/lead-gen-processing-status-migration.mdx` (Step 4 table). Omitted `status` defaults to `success` so existing call sites keep working unchanged.
+
+4. **CRM workflows** — replace any hardcoded CRM `state_key` string literals with imports from `@elevasis/core/organization-model`:
+
+```ts
+import {
+  CRM_DISCOVERY_REPLIED_STATE,
+  CRM_DISCOVERY_LINK_SENT_STATE,
+  CRM_REPLY_SENT_STATE,
+  CRM_FOLLOWUP_1_SENT_STATE,
+  // ...
+} from '@elevasis/core/organization-model'
+
+// before:
+await acqDb.transitionItem({ ..., stateKey: 'reply_sent' })
+
+// after:
+await acqDb.transitionItem({ ..., stateKey: CRM_REPLY_SENT_STATE.stateKey })
+```
+
+The runtime string values are unchanged; this is a mechanical substitution that aligns workflows with the canonical source. The API now validates `stateKey` for the new `PATCH /deals/:dealId/state` route, but `transitionItem` retains existing acceptance behavior for backward compatibility during rollout.
+
+5. **Reading `acq_deal_activity_log`** — pattern-matchers should accept `state_changed_manually` as a new event kind alongside the existing `state_change`. Manual state edits carry a user id and optional reason; workflow-driven state writes continue to use `state_change`.
+
+6. **Lead-gen progress consumers** — if your project reads `GET /acquisition/lists/:listId/progress`, the response shape now exposes attempted-coverage fields. The legacy `{ done, total }` shape no longer ships; consumers should switch to `attempted / total` for completion percentages and use the per-status counts (`success`, `noResult`, `skipped`, `error`, `other`, `notAttempted`) for outcome rendering.
+
+7. **`processing_state` data shape** — running rows now carry string statuses (`"success" | "no_result" | "skipped" | "error"`). Legacy `true` values continue to be normalized server-side. Direct SQL consumers should treat both shapes as readable; new writes should always emit strings.
+
+## Verification
+
+After upgrading and applying the actions above:
+
+- `pnpm check-types` clean across project packages
+- `pnpm test` for any operations workflows that exercise `listTool.update*Stage` signatures
+- Spot-check a CRM deal drawer in your project's command-center: state dropdown should appear under the Summary block when the deal has a stage; an "Unstaged" staging affordance should appear when `stage_key` is null
+- Spot-check a lead-gen list-detail page: progress bars should render stacked segments, with the headline percentage reflecting attempted coverage rather than only successful rows
+- `GET /acquisition/lists/:listId/progress` response should carry the new attempted-coverage shape
+- Manual deal state changes through the new UI should append `state_changed_manually` rows in `acq_deal_activity_log`
+
+## Not handled by /git-sync
+
+`/git-sync` propagates template-authored files (package baselines, scaffold doc copies, sync-managed shells) but does NOT:
+
+- run `pnpm up @elevasis/core @elevasis/ui @elevasis/sdk --latest` for you — bump deps explicitly after this train publishes
+- rewrite hardcoded `state_key` literals in your CRM workflows — Action 4 is a manual substitution
+- backfill historical `processing_state: true` JSONB values to `"success"` strings — the platform monorepo ran a one-shot SQL conversion for its prod data on 2026-04-29; your project owns its own backfill if you want clean string-only rows. API normalization makes the backfill optional for correctness.
+- regenerate workflow status writes — Action 3 is a code-level change in your operations workflows
+- rebuild your `command-center` after the `@elevasis/ui` upgrade — run your project's normal build/dev cycle

package/reference/claude-config/sync-notes/2026-05-02-crm-ownership-next-action.md

@@ -0,0 +1,58 @@
+# CRM Ownership and Next-Action Projection
+
+## Why this note exists
+
+This release train ships CRM ownership and next-action projection across the shared core, UI, API, and Elevasis operations bundle.
+
+Shared CRM deal responses now carry nullable `ownership` and `nextAction` values derived from activity history. The CRM list and detail surfaces render the move owner directly, and detail actions prefer the projected `nextAction` before falling back to ownership-aware derivation. The Elevasis operations bundle also writes canonical follow-up and deferred-next-step activity events so ownership can sort consistently.
+
+## Applies to
+
+Template-derived projects that:
+
+- consume `@elevasis/core/business/acquisition/api-schemas` deal list or detail response types
+- render CRM list, detail, or action surfaces from `@elevasis/ui`
+- author CRM operations workflows that append or interpret deal activity events
+- read `activity_log` rows and classify who owns the next move
+
+Projects with no CRM surface and no `acq_deals` workflow logic can ignore this train.
+
+## Required actions
+
+1. Pull template changes with `/git-sync` after this train publishes so package baselines for `@elevasis/core` and `@elevasis/ui` are refreshed.
+
+2. Upgrade shared packages in the derived project after the publish stages complete:
+
+```bash
+pnpm up @elevasis/core @elevasis/ui --latest
+```
+
+3. Audit any project-owned CRM workflow code that writes activity events. Outbound follow-up should emit `followup_email_sent`, and "lead will check / get back to us" replies should emit `lead_deferred_next_step` when they defer our next action.
+
+4. Audit any project-owned CRM UI code that computes available actions locally. Prefer the server-projected `nextAction` when present, and suppress send-reply affordances when `ownership` is `them`.
+
+5. If the project deploys an operations bundle with CRM reply or follow-up handlers, redeploy that bundle after package upgrades so runtime activity writes match the new ownership derivation:
+
+```bash
+pnpm -C operations exec elevasis-sdk deploy --prod
+```
+
+## Verification
+
+After upgrading:
+
+- `pnpm check-types` passes in project packages that consume CRM types or UI.
+- CRM list rows show the expected move owner for deals with inbound replies, outbound replies, follow-ups, reminders, booking nudges, and deferred-next-step replies.
+- CRM detail actions expose Send Reply only when the server-projected action and ownership allow it.
+- Operations tests or smoke probes confirm follow-up handlers emit `followup_email_sent`.
+- A CRM reply where the lead says they will check internally records `lead_deferred_next_step` and sorts after the inbound reply event.
+
+## Not handled by /git-sync
+
+`/git-sync` does not:
+
+- publish `@elevasis/core` or `@elevasis/ui`
+- run package upgrades inside derived projects
+- redeploy project-owned operations bundles
+- rewrite project-owned CRM workflow logic that still emits legacy activity event names
+- verify or repair historical `activity_log` rows in project databases