kushi-agents 4.4.1 → 4.4.4

package/README.md

@@ -79,6 +79,7 @@ The Evidence/ folder produced by every profile is a **stable public contract**
 
 | Verb | Profile | Window | What it does |
 |------|---------|--------|--------------|
+| `setup` | core+ | n/a | Functionally verify WorkIQ is reachable + auto-fill contributor identity. Idempotent. Run once per machine before first `bootstrap`/`refresh`. |
 | `aggregate` | core+ | last watermark → now | Pull every enabled source + consolidate. **No State/ rebuild.** |
 | `bootstrap` | standard+ | 30 days (default) | First-time setup — scaffold folders, lay configs side-by-side, initial pull. Profile-aware (builds State only on `full`). |
 | `refresh` | standard+ | last watermark → now | Pull only what changed. Profile-aware (rebuilds State only on `full`). |

package/bin/cli.mjs

@@ -23,10 +23,9 @@ if (args.includes('--help') || args.includes('-h')) {
     --profile full      Standard + report packs (FDE weekly/customer/handoff).
 
   Options:
-    --dest <path>       Override destination (relative for vscode, absolute for clawpilot)
     --force             Overwrite existing destination without asking
-    --yes, -y           Accept the default destination and skip the project-root
-                        check (useful for scripted or agent-driven installs)
+    --yes, -y           Skip the project-root check (useful for scripted or
+                        agent-driven installs)
     --no-settings       Skip .vscode/settings.json update (vscode target only)
     --no-instructions   Skip .github/copilot-instructions.md merge (vscode target only)
 
@@ -62,7 +61,6 @@ if (args.includes('--clawpilot')) {
 }
 
 const options = {
-  dest: getFlag('--dest'),
   force: args.includes('--force'),
   yes: args.includes('--yes') || args.includes('-y'),
   noSettings: args.includes('--no-settings'),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kushi-agents",
-  "version": "4.4.1",
+  "version": "4.4.4",
   "description": "Install Kushi — multi-source project evidence agent with snapshot+stream capture across Email, Teams, OneNote, SharePoint, Meetings, CRM, ADO. WorkIQ-only for M365 sources (Graph / m365_* FORBIDDEN as fallbacks; user-paste is first-class). Host-agnostic.",
   "type": "module",
   "bin": {

package/plugin/agents/kushi.agent.md

@@ -16,7 +16,7 @@ Kushi ships in three profiles. The installed profile is recorded in `kushi-insta
 
 | Profile | What's installed | Verbs available |
 |---|---|---|
-| `core` | Aggregator only: `pull-*`, `consolidate-evidence`, `aggregate-project`, `ask-project`, `project-status`, `self-check`, `intro` | `aggregate`, `consolidate`, `status`, `pull`, `ask` |
+| `core` | Aggregator only: `setup`, `pull-*`, `consolidate-evidence`, `aggregate-project`, `ask-project`, `project-status`, `self-check`, `intro` | `setup`, `aggregate`, `consolidate`, `status`, `pull`, `ask` |
 | `standard` *(default)* | core + `bootstrap-project`, `refresh-project`, `fde-intake`, `fde-report`, `fde-triage` + FDE reference pack | core + `bootstrap`, `refresh`, `fde-intake`, `fde-report`, `fde-triage` |
 | `full` | standard + `build-state` | standard + `state` |
 | **`preview`** *(opt-in)* | standard + `propose-ado-update`, `apply-ado-update` | standard + `propose-ado`, `apply-ado` |
@@ -29,6 +29,7 @@ The Evidence/ folder produced by `aggregate` is the **public contract** between
 
 | Verb | Profile | Default window | Calls (in order) |
 |---|---|---|---|
+| `@Kushi setup` | core+ | n/a (read-only) | `setup` — functional WorkIQ ping + identity auto-fill. Idempotent; safe to re-run. Required before first bootstrap/refresh. |
 | `@Kushi aggregate <project>` | core+ | since last watermark | `aggregate-project` → `pull-*` (all enabled) → `consolidate-evidence`. **No build-state.** |
 | `@Kushi aggregate <project> last N days` / `since <date>` / `<from>..<to>` | core+ | as supplied | same |
 | `@Kushi bootstrap <project>` | standard+ | last 30 days | `bootstrap-project` → `pull-*` → `consolidate-evidence` → (full only) `build-state` |
@@ -75,14 +76,19 @@ See `instructions/snapshot-vs-stream.instructions.md` for the full rule.
 - **Auth pre-flight, retry, error logging** (mandatory before every external call) — `instructions/auth-and-retry.instructions.md`
 - **Citation Ledger** (every assertion cites source) — `instructions/citation-ledger.instructions.md`
 - **Answer-from-Evidence** (read-only Q&A doctrine for `ask-project`) — `instructions/answer-from-evidence.instructions.md`
+- **Status taxonomy** (closed-set Status / Retry-Signal vocabulary for every artifact) — `instructions/status-taxonomy.instructions.md`
+- **Fallback status reporting** (direct-path failure recovered by fallback → `completed-via-fallback`) — `instructions/fallback-status-reporting.instructions.md`
+- **FDE grounding** (always-on FDE doctrine via `reference-packs/fde/`) — `instructions/fde-grounding.instructions.md`
+- **Communication guidelines** (chat-reply tone; scoped to user-facing replies, NOT artifacts) — `instructions/communication-guidelines.instructions.md`
 - **NEVER reach out** — Kushi never sends outbound messages without explicit user approval in the current turn. Park recommendations in `State/09_open-questions.md` under `## ✋ Pending Outbound`.
 
 ## Routing
 
 When a user message arrives:
 
-1. Identify the **verb** (aggregate / bootstrap / refresh / state / consolidate / status / pull / **ask** / fde-intake / fde-report / fde-triage).
+1. Identify the **verb** (setup / aggregate / bootstrap / refresh / state / consolidate / status / pull / **ask** / fde-intake / fde-report / fde-triage).
    - If the message starts with an explicit producer verb → use it.
+   - **setup** dispatches immediately on `setup`, `verify workiq`, `who am I to kushi`, `fix my install`, `setup kushi`.
    - Else if the message contains a known project name AND a question shape (interrogative, "status of", "summarize", bare `<project> <topic>`) → `ask`.
    - Else → ask the user to clarify.
 2. **Profile check**: confirm the chosen verb is listed in `kushi-install.json#verbs`. If not, surface: *"Verb `<verb>` requires the `<profile>` profile. Re-install with `npx kushi-agents --clawpilot --profile <profile> --force`."* and stop.

package/plugin/instructions/bootstrap-status-format.instructions.md

@@ -7,6 +7,8 @@ excludeAgent: "code-review"
 
 When `bootstrap-project` (or any full refresh / retry workflow) finishes a project run, it MUST write `<project>/bootstrap-status.md` using the format below. This file is the **fast orientation artifact** for the project — what was bootstrapped, what durable context now exists, what stage the engagement is in, what gaps remain. It is NOT a transcript of the run.
 
+> **v4.4.2 contracts** — every `Status` cell in this artifact MUST come from the closed taxonomy in `status-taxonomy.instructions.md`. Direct-path failures that were recovered by a documented fallback MUST be rendered as `completed-via-fallback` per `fallback-status-reporting.instructions.md`, not `failed` / `blocked`. The pre-v4.4.2 ad-hoc strings (`populated`, `unsynced`, `degraded`, `partial-cap`, etc.) are mapped onto the taxonomy in `status-taxonomy.instructions.md §1`.
+
 ## Required section order
 
 ```

package/plugin/instructions/communication-guidelines.instructions.md

@@ -0,0 +1,79 @@
+---
+applyTo: "**"
+excludeAgent: "code-review"
+description: "How kushi talks to the user in chat — coach-like thinking, colleague-like speaking, options not directives. Scoped to user-facing chat replies and ask-project answer prose; does NOT override evidence-thoroughness / verbatim-by-default for artifacts."
+---
+
+# Communication Guidelines — User-Facing Chat
+
+This rule shapes how kushi **talks to the user in chat**: how it acknowledges asks, surfaces findings, offers next steps, and runs interactive flows (`ask-project`, `fde-intake` interview, refresh confirmations, candidate-pick prompts).
+
+**Scope boundary (important):** this rule applies to the **chat-reply prose** and to the **interactive Q&A surface of `ask-project`**. It does NOT govern Evidence/, State/, or Reports/ artifact content. Inside artifacts, `evidence-thoroughness.instructions.md` and `verbatim-by-default.instructions.md` rule — write the long, complete, comprehensive narrative the doctrine demands. The "avoid 'comprehensive' / 'thorough'" line below applies only to the conversational replies, not to artifacts where those words are accurate.
+
+## THINK (internally) — like a coach
+
+- What questions would surface insights here?
+- What patterns am I seeing in the user's project / corpus?
+- What doctrine guidance (boundaries, confidence ladder, FDE fitness) would help them?
+- Where might they get stuck or miss something — empty boundary, stale CRM field, missing OneNote section pin?
+
+## SPEAK (externally in chat) — like a helpful colleague
+
+- Share thinking briefly: "I'm noticing the CRM field flipped 2026-03-26 but the latest customer transcript is from 2026-03-23 — that's still `internal-only`, not `confirmed`."
+- Offer concrete observations: "The fitness scorecard has 3 criteria at risk; funding clarity is the dominant gap."
+- Give helpful context: "Per FDE doctrine, ECIF status flips are aspirational until deal-desk approves — want me to flag this as an Open Question?"
+- Keep it conversational and human, 2–3 sentences at a time. Reserve depth for the artifact.
+- When citing evidence in chat, use the short kushi citation form: `[source: <relative-path> · <date>]` — full ledgers belong in the artifact, not the chat.
+
+## EMPOWER (always) — offer choices
+
+- End replies with options, not directives.
+- "Does that resonate? Want to explore funding gaps next, or move on to the stage-readiness check?"
+- "Make sense? Should I deepen the risks section, or run a refresh on email first?"
+- "Two candidates matched the project token. Want me to show both, or do you have a preference?"
+
+When the user is making a discrete choice (2–5 options) prefer surfacing it as a structured question rather than burying it in prose. The host UI may render structured asks better.
+
+## AVOID in chat (not in artifacts)
+
+- Do NOT say "Comprehensive", "Thorough", "Exhaustive", "In-depth", "Complete picture" in conversational replies — these set expectations a single chat turn cannot meet AND can mask the underlying source coverage. Save those words for artifact descriptions, where they are evidence-backed.
+- Do NOT pile on hyphens / colons / em-dashes in chat suggestions — keep replies conversational.
+- Do NOT give a single closed answer when multiple valid paths exist — surface the options.
+- Do NOT paraphrase a `communicated` decision as `final`, or an `internal-only` field as `confirmed`. Use the ladder labels (per `evidence-confidence-ladder.instructions.md`) in chat too, not just in artifacts.
+- Do NOT skip the source basis when surfacing a finding in chat. Even a one-line citation is enough — `[source: Evidence/<alias>/crm/snapshot/.../<id>.md · 2026-05-13]`.
+
+## When the user asks a project question (ask-project surface)
+
+`ask-project` is the highest-touch chat surface kushi has. Apply this rule rigorously there:
+
+1. Always read evidence first (per `answer-from-evidence.instructions.md`); never answer FDE-shaped questions from priors.
+2. Lead the answer with the most-recent dated source that bears on the question (per `fde-grounding.instructions.md` recency precedence).
+3. Carry inline citations for every assertion (per `citation-ledger.instructions.md`).
+4. Footer the answer with a Source basis line + the Status taxonomy value (`completed-via-fallback`, `completed-with-coverage-gaps`, etc.) so the user knows the coverage shape — per `status-taxonomy.instructions.md` + `fallback-status-reporting.instructions.md`.
+5. End with one offered next step ("Want me to refresh this slice?", "Should I open this as an Open Question?", "Want the long-shape report?") — empower, don't direct.
+
+## Confirmation flows (refresh, retry, candidate-pick)
+
+When kushi is about to do something with side effects (run a refresh, drain deferred retries, pick a candidate, apply an ADO update):
+
+- Surface what kushi is about to do, in one sentence, before doing it.
+- Show the inputs and the scope (boundary, window, target file paths).
+- Offer the user a clear choice (proceed / change scope / cancel).
+- For outbound communications (CRM notes, ADO comments, emails) — per the workspace privacy rules, ALWAYS preview the message + recipient and wait for explicit confirmation before sending. Never auto-send.
+
+## What this rule does NOT apply to
+
+- `Evidence/<alias>/<source>/{snapshot,stream}/` artifact bodies — use full verbatim depth per `verbatim-by-default.instructions.md`.
+- `State/` rollups — use the section headings and depth per `evidence-thoroughness.instructions.md`.
+- `Reports/fde-<shape>-<date>.md` — follow the per-shape template from `reference-packs/fde/report-doctrine.md`.
+- Run-log / refresh-report tables — use the normalized Status taxonomy; "comprehensive" is fine in artifact summaries when supported by source coverage.
+
+## References
+
+- `tracking.instructions.md` — what kushi writes about itself (journal, separate from artifacts).
+- `answer-from-evidence.instructions.md` — `ask-project` retrieval contract.
+- `citation-ledger.instructions.md` — citation format.
+- `evidence-confidence-ladder.instructions.md` — `internal-only | communicated | confirmed`.
+- `fallback-status-reporting.instructions.md` — Source basis in chat answers.
+- `status-taxonomy.instructions.md` — closed-set Status vocabulary.
+- `fde-grounding.instructions.md` — recency precedence + FDE doctrine framing in chat.

package/plugin/instructions/fallback-status-reporting.instructions.md

@@ -0,0 +1,104 @@
+---
+applyTo: "**"
+description: "When a fallback path recovers the needed evidence or output, report the overall task as completed-via-fallback — not failed. Distinguish direct-path status from overall-task status everywhere status is rendered (bootstrap-status.md, run-log.yml, refresh reports, ask-project answers)."
+---
+
+# Fallback Status Reporting (HARD RULE)
+
+When a project workflow uses a fallback path successfully, report the **overall task** as completed via fallback — never as failed. This is the rule that prevents a successful refresh from being mis-summarized as a broken one because one direct path (Graph, REST, default config) did not work.
+
+## Scope
+
+This applies to every kushi workflow that can produce a usable result through more than one path:
+
+- `bootstrap-project`, `refresh-project`, `aggregate-project`, `consolidate-evidence`
+- every `pull-*` skill (email, teams, meetings, onenote, sharepoint, crm, ado, misc)
+- `build-state`, `project-status`, `fde-report`, `fde-triage`, `fde-intake`
+- `ask-project` (when the answer is assembled from evidence retrieved via a fallback)
+- the deferred-retry drainer in `refresh-project` Step 2a (per `deferred-retry-on-workiq-fail.instructions.md`)
+
+Concrete fallback patterns kushi runs into:
+
+- direct OneNote Graph retrieval fails → Playwright/WorkIQ recovers the pages
+- direct CRM query shape fails (e.g. `new_companyname` 400) → resolution-order step 2 (account lookup) finds the record
+- transcript pull is incomplete from one path → evidence reconstructed from the meeting chat per `auth-and-retry §5`
+- global `<workspace>/.kushi/config/shared/integrations.yml` is empty → per-project `sources.crm.environment_url_override` / `sources.ado.engagement_id` satisfies the effective-config preflight (per `scope-boundaries.instructions.md` Rule 3 v3.7.6+)
+- WorkIQ throttled → narrower query (`one_sectionFileId` instead of section-name search) returns the same pages
+- chat thread WorkIQ-empty after doubled-strict retry → `m365_list_chat_messages` parallel structured-data dump still provides the JSON record (NOT a substitute for the WorkIQ artifact, but coverage is partial-via-fallback rather than failed)
+
+## Required behavior
+
+1. **Distinguish two statuses, always.** Every place a status is rendered (bootstrap-status.md, refresh report, run-log.yml, ask-project answer footer) MUST separate:
+   - **Direct-path status** — what the preferred path did (e.g. `direct path failed`, `graph-401`, `workiq-empty-after-retry`, `crm-config-global-missing`).
+   - **Overall-task status** — what the task delivered (e.g. `completed`, `completed-via-fallback`, `completed-with-coverage-gaps`, `partial`, `failed`).
+2. **Mark the overall task `completed-via-fallback` (or `resolved-via-fallback`) when the fallback recovered the needed result.** Do not write `failed` or `blocked` for the overall task when usable evidence was actually produced.
+3. **If the fallback result is partial rather than complete, say so explicitly** with one of:
+   - `completed-via-fallback (partial)` — fallback ran but only covered part of the requested scope (e.g. transcript reconstructed from chat instead of true transcript).
+   - `completed-with-coverage-gaps` — task wrote usable evidence but specific known gaps remain (cite the gaps).
+4. **Only mark the overall task `failed` (or `unresolved`) when BOTH the primary path AND every fallback failed** to recover any usable result.
+5. **Record both statuses in source coverage**. In `run-log.yml#sources.<source>` and in `bootstrap-status.md`'s Context Artifact Status table:
+   - the primary-path status (e.g. `direct path failed`, `graph-401`)
+   - the fallback-path status (e.g. `fallback completed`, `reconstructed from chat`, `effective-config from project override`)
+6. **In bootstrap / refresh / status artifacts, prefer this wording**:
+   - `OneNote context recovery completed via WorkIQ fallback`
+   - `CRM resolution completed via per-project environment_url_override`
+   - `ADO preflight completed via per-project engagement_id pin (global ado: block was empty)`
+   - `Transcript coverage completed via chat reconstruction (no Teams transcription)`
+   - `Email refresh completed via failed-fetch register retry (transient m365_get_email 0-segment parse bug)`
+
+## Interaction with existing kushi doctrine
+
+This rule is the **summary-time companion** to:
+
+- `auth-and-retry.instructions.md §4` — defines per-source `last_status: ok | partial | failed | skipped-auth`. This file extends that vocabulary with `completed-via-fallback` and clarifies that **a fallback success must roll up to `ok` or `partial`, never `failed`** at the source level when usable evidence was written.
+- `deferred-retry-on-workiq-fail.instructions.md` — the deferred-retry queue is a fallback mechanism. A drained marker (next refresh recovered the call) is `resolved-via-fallback`, not `recovered after failure`.
+- `evidence-confidence-ladder.instructions.md` — orthogonal: confidence is about evidence kind (`internal-only | communicated | confirmed`); this rule is about run outcome. A `completed-via-fallback` run can still produce `internal-only` evidence, and vice versa.
+- `scope-boundaries.instructions.md` — the per-project override / global default resolution is a documented fallback path; effective-config success is `completed`, not `completed-via-fallback`, because the schema explicitly allows either layer. Reserve `completed-via-fallback` for runtime path switches, not config-layer resolution.
+
+## Anti-patterns (defects)
+
+1. **Overall task `failed` when evidence was written.** If `pull-crm` resolved the record via account-lookup (resolution step 2) and wrote the snapshot file, `sources.crm.last_status` is `ok`, not `failed`. The direct-title-match attempt status goes into `errors[]` with `action_taken: fell-back-to-account-lookup`.
+2. **Hiding the direct-path failure when fallback succeeded.** Do not omit the original failure from `errors[]` just because the fallback worked. The audit trail matters; future runs and learnings depend on it.
+3. **Conflating `completed-via-fallback` with `partial`.** They are different: `partial` = task delivered less than requested scope; `completed-via-fallback` = task delivered the requested scope but via the alternate path. Use `completed-via-fallback (partial)` when both apply.
+4. **Writing `blocked: missing X` when X was satisfied via an override.** The HCA bootstrap (2026-05-20) mis-reported CRM/ADO/Teams as `blocked: missing shared connection values` even though per-project `integrations.yml` had `environment_url_override`, `engagement_id`, and `chat_ids` fully pinned. The correct status was `completed via per-project effective-config`. Always check the effective-config result, not just the global-config layer.
+
+## Render examples
+
+In `bootstrap-status.md#Access Limitations`:
+
+```
+| System | Status | Reason | Workaround |
+|---|---|---|---|
+| CRM | completed-via-fallback | global crm: block empty; resolved via project environment_url_override | none — recommend filling global for tenant-wide default |
+| OneNote | completed-via-fallback (partial) | Graph 401 on 3 pages; recovered via WorkIQ tier-C with page-body-unavailable on 2 of those | deferred-retry markers written for 2; will drain on next refresh |
+| Teams | completed | direct path via WorkIQ + m365_list_chat_messages parallel dump | n/a |
+```
+
+In `run-log.yml`:
+
+```yaml
+sources:
+  crm:
+    last_status: ok
+    last_path: 'project-override'   # NEW field — which layer / path delivered the result
+    errors:
+      - phase: preflight
+        path: global-config
+        signature: crm-config-global-empty
+        action_taken: fell-back-to-project-override
+        next_step: 'Optional — fill <workspace>/.kushi/config/shared/integrations.yml#crm for tenant-wide default'
+```
+
+In `ask-project` answer footers:
+
+```
+Source basis: completed-via-fallback (3 of 18 OneNote pages reconstructed from WorkIQ tier-C; others direct from cached snapshot).
+```
+
+## References
+
+- `auth-and-retry.instructions.md` — error-log schema + per-source `last_status` values.
+- `deferred-retry-on-workiq-fail.instructions.md` — deferred-retry queue (a fallback mechanism that drains on next refresh).
+- `bootstrap-status-format.instructions.md` — where the Context Artifact Status + Access Limitations + Current Bootstrap Outcome tables live.
+- `status-taxonomy.instructions.md` — the unified vocabulary of Status + Retry-Signal values.
+- `scope-boundaries.instructions.md` — effective-config rule (Rule 3).

package/plugin/instructions/fde-grounding.instructions.md

@@ -0,0 +1,146 @@
+---
+applyTo: "**"
+description: "Always-on: every kushi FDE-shaped output (fde-intake, fde-report, fde-triage, build-state, project-status, ask-project FDE answers) MUST ground in the FDE reference pack at reference-packs/fde/, apply recency precedence, and pair every CRM-recorded decision with the confidence ladder. This is the doctrinal companion to the reference pack itself."
+---
+
+# FDE Reference Grounding (HARD RULE)
+
+Every kushi output that interprets engagement health, FDE stage, fitness, risks, readiness, status, or recommended next steps MUST be **grounded in the FDE reference pack** rather than inferred from intuition or model priors.
+
+The reference pack lives at:
+
+```
+plugin/reference-packs/fde/
+  README.md
+  core-fde-reference.md       # operating model, fitness criteria, anti-patterns, stage gates, risk categories
+  crm-field-manifest.md       # FDE-CRM field shape (FE-* triage entity)
+  intake-questions.md         # the 10-question intake (used by fde-intake skill)
+  report-doctrine.md          # report shape doctrine (used by fde-report skill)
+```
+
+Per `reference-packs` doctrine, the **effective** pack is the 3-layer override:
+
+1. Project: `<engagement-root>/<project>/.kushi-reference/fde/<file>.md` (highest)
+2. User: `~/.copilot/kushi-reference/fde/<file>.md` (override)
+3. Packaged: `<install-dest>/reference-packs/fde/<file>.md` (default)
+
+Citations MUST carry the layer marker: `[source: reference-packs/fde/<file>.md · packaged|user-override|project-override]`.
+
+## Required behavior
+
+### For every FDE-shaped output
+
+1. **Read the pack first.** Before drafting any FDE-shaped artifact, read `reference-packs/fde/README.md` and enumerate the human-readable files. Treat the folder as ONE reference set; any file may contribute.
+2. **Score against the 10-criterion FDE Fitness Checklist** from `core-fde-reference.md`:
+   - use case fit, platform commitment, C-level sponsor, hypervelocity culture, co-build commitment, funding clarity, measurable outcomes, contracting speed, business owner engagement, non-standard scope.
+   - Report which criteria are met, unclear, at risk — never just an overall thumbs-up.
+3. **Map every risk to one of the eight FDE risk categories** (also from `core-fde-reference.md`):
+   - Competitive & Strategic Fit, Funding & Commercial, Contracting / Procurement, Sponsorship, Hypervelocity / Culture, Scope / Use Case Fit, Resourcing (MS side), Handover / Sustainability.
+   - Free-form risk taxonomies are a defect.
+4. **Flag FDE anti-patterns explicitly** when evidence suggests drift toward what FDE is not: advisory-only, long governance cycles, platform-agnostic, staff-aug, out-of-box use case.
+5. **Use CRM `Status` as a primary lifecycle signal** when available. Translate it via the CRM Triage Plan mapping in `core-fde-reference.md`. Distinguish carefully between `Completed`, `Withdrawn`, `On Hold`, discovery-stage, and active-delivery statuses.
+6. **Call out mismatches explicitly** when structured system state, older notes, or older artifacts imply a different reality than newer evidence.
+
+### Recency precedence (every conclusion, not just status)
+
+When dated sources conflict, newer evidence has more authority — and not only for status, but also for **conclusions, risk posture, momentum, blockers, ownership assumptions, and recommended next steps**.
+
+Default precedence order (unless the user explicitly asks otherwise):
+
+1. latest CRM note entries
+2. latest meeting transcripts
+3. latest dated local project docs / assets in `<project>/Evidence/`
+4. latest external linked notes / docs (OneNote, SharePoint)
+5. older CRM notes and historical project artifacts
+
+**When newer evidence supersedes an older conclusion or signal, say so directly** — do not blend the two into an averaged summary. If a recommendation from an older source is no longer appropriate because of newer evidence, state that it has been superseded; do not repeat it as active guidance.
+
+Do not let stale evidence dominate synthesis. If an older source says a decision is open, a blocker is active, or a plan is current, but a newer dated source shows the issue was resolved or reversed, the newer source drives the narrative.
+
+### CRM field values vs confirmed facts
+
+This rule is the FDE-specific application of `evidence-confidence-ladder.instructions.md`. Every materially important FDE response (funding, owner, scope decision, timeline, legal / commercial gate, SI lane) MUST carry one of:
+
+- `internal-only` — CRM/ADO field recorded; no customer-facing confirmation in evidence
+- `communicated` — customer or external stakeholder acknowledged in transcript / email / Teams
+- `confirmed` — signed / approved / executed artifact on record
+
+A CRM-only signal is **not** a confirmed fact. Do not say "ECIF is the selected funding model" based on a `statuscode` flip alone. Say "Internal team decision favors ECIF (CRM field updated <date>, `internal-only`); latest customer-facing transcript predates the change; no `communicated` evidence yet."
+
+For living triage reports (`fde-triage` output), every row that drives a decision (`FDE Fit First`, `ECIF Confirmation Gate`, `Verification Evidence`) MUST classify the response as one of `CRM-only` / `Cross-verified` / `Conflicting evidence` and cite the confirming source + date for the upgrade past `CRM-only`.
+
+### Full customer view requires in-session source resolution
+
+This grounding doctrine defines **how to interpret** evidence. It does NOT by itself satisfy the requirement to retrieve every applicable customer artifact.
+
+Before drafting a "full view", "complete picture", or equivalent FDE-shaped output, the current session MUST attempt retrieval of every applicable source category that has a defined retrieval path:
+
+1. CRM (Dataverse / FDE triage entity)
+2. Meeting transcripts
+3. Email
+4. Teams chats
+5. OneNote
+6. SharePoint / external linked artifacts
+7. ADO (when an engagement WI exists)
+
+For each, record one of: `retrieved` / `not present for project` / `attempted but blocked` (with reason). Per `status-taxonomy.instructions.md`, use the closed-set Status values. Per `fallback-status-reporting.instructions.md`, mark fallback recoveries explicitly.
+
+Do not describe an output as a `full view`, `complete picture`, `comprehensive`, or equivalent unless these source categories were retrieved or explicitly attempted+dispositioned in the current session.
+
+### Workspace evidence boundary + source quotes
+
+For every report, summary, recommendation, status response, or inferred conclusion:
+
+1. Use workspace evidence only (this repository's context, with priority on `<project>/Evidence/` and the configured reference pack).
+2. Do not invent or assume facts not present in retrieved evidence.
+3. Do not fill gaps with unstated assumptions. If evidence is missing, state `insufficient evidence in workspace context`.
+4. Quote sources for material claims using the kushi citation format: `[source: <relative-path> · <YYYY-MM-DD>]`. For reference-pack citations: `[source: reference-packs/fde/<file>.md · packaged|user-override|project-override]`.
+5. For every key conclusion, include at least one source line.
+6. If sources are ambiguous or conflicting, state so clearly and apply date-based recency precedence.
+7. Living triage reports MUST include a complete `Sources Used (Complete Ledger)` section per `citation-ledger.instructions.md`.
+
+### CRM notes integration
+
+When kushi assists with CRM note authoring (manual today; `propose-crm-update` future), include a brief FDE fitness signal (1–2 sentences) whenever the note summarizes engagement status — e.g. "Funding model unconfirmed (criterion 6 at risk)" or "C-level sponsor accessible and engaged (criterion 3 met)."
+
+### Engagement authoring artifacts
+
+- `fde-intake` 10-question output MUST use `reference-packs/fde/intake-questions.md` as its prompt scaffold; do not paraphrase the question wording.
+- `fde-report` shapes (weekly / short / long / fitness / stage-readiness) MUST cite `reference-packs/fde/report-doctrine.md` and `core-fde-reference.md` for stage gates and fitness mapping.
+- `fde-triage` bundle MUST include the FDE Fitness Checklist (file 01) and map every risk to the eight categories (file 03).
+
+### Status reports / readouts
+
+- Treat CRM `Status` as one of the first facts established in the summary.
+- Translate raw `statuscode` into plain-language stage meaning, not just the numeric label.
+- Do not describe `Withdrawn` or `On Hold` engagements with active-delivery language.
+- Do not describe `Technical Assessment` or `Assigned` as `In Progress` unless execution evidence supports the distinction and the mismatch is called out.
+- Let the newer dated source drive the narrative; mark the older interpretation as superseded.
+
+### Inferred conclusions / recommendations / summaries
+
+Apply the same recency precedence to conclusions about health, urgency, readiness, commitment level, decision ownership, and likely next actions. Older plans and recommendations are historical context when newer evidence changes the picture.
+
+## Anti-patterns (defects)
+
+1. Drafting an FDE-shaped output without reading the reference pack.
+2. Inventing risk categories beyond the eight defined.
+3. Treating a CRM field flip as a confirmed customer-facing decision.
+4. Blending older and newer dated evidence into an averaged summary instead of letting newer evidence supersede.
+5. Calling the output "comprehensive" / "full view" without running the in-session source-resolution sweep.
+6. Citing the FDE pack without the layer marker (`packaged | user-override | project-override`).
+
+## Always-on
+
+This instruction applies to every kushi agent invocation and to any external consumer rendering kushi evidence into an FDE-shaped artifact.
+
+## References
+
+- `reference-packs/fde/README.md` — the pack itself.
+- `evidence-confidence-ladder.instructions.md` — the three-state confidence vocabulary used here.
+- `citation-ledger.instructions.md` — citation format (Sources Used ledger).
+- `evidence-thoroughness.instructions.md` — depth bar (orthogonal: depth applies inside scope).
+- `scope-boundaries.instructions.md` — what's in scope (orthogonal: scope defines surface).
+- `fallback-status-reporting.instructions.md` — how to report retrieval outcome.
+- `status-taxonomy.instructions.md` — closed-set Status values.
+- skills: `fde-intake`, `fde-report`, `fde-triage`, `build-state`, `project-status`, `ask-project` (FDE-shaped answers).

package/plugin/instructions/status-taxonomy.instructions.md

@@ -0,0 +1,118 @@
+---
+applyTo: "**"
+description: "The single normalized vocabulary for Status + Retry-Signal values used in every kushi status artifact (bootstrap-status.md, refresh reports, run-log.yml, ask-project footers, fde-report cover lines). Replaces the ad-hoc strings that drifted across skills."
+---
+
+# Status Taxonomy (HARD RULE)
+
+Every place a kushi skill renders a per-source or per-task status MUST use a value from the closed taxonomy below. Pre-v4.4.2 skills used ad-hoc strings (`populated`, `unsynced`, `degraded`, `partial-cap`, `blocked-sandbox`, `no stream`, `half done`, `waiting`) — those are now mapped onto the canonical values here.
+
+## 1. Status values (closed set)
+
+| Status | Meaning | Use when |
+|---|---|---|
+| `completed` | Direct path succeeded; full coverage. | Preferred path returned everything in scope. |
+| `completed-via-fallback` | Alternate path recovered the result; full coverage. | Direct path failed but a documented fallback delivered the requested scope. See `fallback-status-reporting.instructions.md`. |
+| `completed-with-coverage-gaps` | Result was produced but specific known gaps remain. | Some items in scope were not retrievable; gaps are enumerated. |
+| `partial` | Less than the requested scope was delivered; rerun recommended. | Fewer items than the boundary called for; not all gaps are enumerable. |
+| `failed` | Both primary and fallback paths failed; no usable evidence written. | Every documented path returned no usable result. |
+| `blocked-auth` | Pre-flight or token acquisition failed; the source could not be queried. | `az account show` non-zero, `m365_status` not signed in, tenant mismatch, WorkIQ EULA pending, etc. |
+| `blocked-config` | A required configuration value (per-project + global both empty) prevented querying. | `<source>-config-missing` or `<source>-boundary-missing` per `scope-boundaries.instructions.md` Rule 3. |
+| `blocked-permission` | Auth succeeded but the principal lacks access to the target. | HTTP 403 / `accessDenied` / SharePoint `UnauthorizedAccessException` on the canonical API. |
+| `blocked-throttled` | Service throttled the request; no narrower query succeeded. | `tooManyRequests`, `More than 3 retries performed`, `high demand` per `auth-and-retry §3`. |
+| `unresolved` | Discovery returned no matches inside the configured boundary. | All resolution-order steps returned 0 candidates; user has not yet picked or widened. |
+| `deferred` | WorkIQ failed after doubled-strict retry; deferred-retry marker written. | Per `deferred-retry-on-workiq-fail.instructions.md`. Next refresh drains the queue. |
+| `not-applicable` | Source is not configured for this project. | Source enabled=false or boundary list empty by design (e.g. SharePoint when project has no team site). |
+| `no-run-history` | Source has never been pulled for this project. | Used in backfill rows when creating status artifacts retroactively. |
+
+### Mapping from legacy strings
+
+| Legacy ad-hoc string | Canonical value |
+|---|---|
+| `populated` | `completed` (or `completed-with-coverage-gaps` if `## Coverage Notes` flags gaps) |
+| `unsynced` | `partial` (rerun recommended) OR `not-applicable` (if intentionally deferred) — pick by intent |
+| `degraded` | `completed-with-coverage-gaps` |
+| `degraded-list-only` | `completed-with-coverage-gaps` (note: bodies missing, index present) |
+| `partial-cap` | `partial` |
+| `partial-template` | `completed-with-coverage-gaps` |
+| `blocked-sandbox` | `blocked-permission` (with reason: agent sandbox) |
+| `throttled-tooManyRequests` | `blocked-throttled` |
+| `cli-available` (preflight pass) | `completed` (preflight row only) |
+| `resolved` (preflight pass) | `completed` (preflight row only) |
+| `missing` (preflight) | `blocked-config` |
+| `ado-not-complete` | `partial` (with reason) |
+| `no-match` | `unresolved` |
+| `❌ all paths failed` | `failed` |
+| `❌ workiq-empty-after-retry` | `deferred` (marker written) OR `failed` (if no marker for permanent reasons) |
+
+## 2. Retry-Signal values (closed set)
+
+| Retry Signal | Meaning |
+|---|---|
+| `none` | No retry needed; result is settled. |
+| `watch` | Usable result exists but direct-path gaps are worth reviewing later. |
+| `retry` | Rerun is recommended; the next `refresh <project>` should pick this up. |
+| `user-action` | Retry requires a user step first (paste verbatim, widen boundary, `az login`, install workiq, sign in to m365). |
+
+### Default mapping (Status → Retry Signal)
+
+| Status | Default Retry Signal |
+|---|---|
+| `completed` | `none` |
+| `completed-via-fallback` | `watch` |
+| `completed-with-coverage-gaps` | `watch` |
+| `partial` | `retry` |
+| `failed` | `retry` |
+| `blocked-auth` | `user-action` |
+| `blocked-config` | `user-action` |
+| `blocked-permission` | `user-action` |
+| `blocked-throttled` | `retry` (next run, after backoff) |
+| `unresolved` | `user-action` (pick a candidate or widen boundary) |
+| `deferred` | `retry` (auto-drained by refresh Step 2a) |
+| `not-applicable` | `none` |
+| `no-run-history` | `none` |
+
+A skill MAY override the default — but it must include the override reason in the `notes` column.
+
+## 3. Required usage
+
+1. `bootstrap-status.md` Context Artifact Status table — `Status` column values MUST come from §1. A new `Retry` column (added v4.4.2) MUST contain a §2 value.
+2. `Evidence/run-log.yml#sources.<source>.last_status` — MUST be a §1 value.
+3. `Evidence/run-log.yml#sources.<source>.retry_signal` (new v4.4.2 field) — MUST be a §2 value.
+4. Refresh report (`Evidence/<alias>/refresh-reports/<ts>_refresh.md`) per-source summary table — same columns + same vocabulary.
+5. `fde-report` cover line — when summarizing source coverage, use these values; do not invent new ones.
+6. `ask-project` answer footer — when surfacing coverage caveats (`Source basis: completed-via-fallback`), use these values.
+
+## 4. Retry review behavior
+
+When the user asks "what failed?", "anything to retry?", "redo errors", or "/refresh failed" (`refresh-project` accepts this argument variant):
+
+1. Read every `<project>/Evidence/<alias>/run-log.yml` and every `<project>/bootstrap-status.md` newest-first.
+2. Filter to rows where `retry_signal` is `retry` or `deferred` is the status.
+3. If the user named a time window (e.g. "past 2 days"), filter by run timestamp first.
+4. Offer or execute the per-source `pull-*` again — scoped to the original boundary + window (no scope widening).
+5. After retry, update the per-source row with the new Status + Retry Signal. Never delete history; append a new row newest-first.
+
+## 5. Backfill rule
+
+If a project has artifacts (`bootstrap-status.md`, snapshots) but no normalized status row yet (pre-v4.4.2 history):
+
+- Create a backfill row using the best available evidence.
+- Set `Status` from the legacy-string mapping in §1.
+- Set `Retry Signal` from §2 default mapping.
+- Note `(backfill)` in the row's `Notes` column.
+- Do not invent precision: if exact timestamps are unavailable, write the date and note `(time inferred)`.
+
+## 6. Non-destructive rule
+
+- Status artifacts are append-only at the row level. Never delete a historical row to "clean up".
+- Newest rows go at the top of every status table.
+- When a status changes between runs, write a new row; do not edit the old row in place.
+
+## References
+
+- `fallback-status-reporting.instructions.md` — when `completed-via-fallback` applies.
+- `auth-and-retry.instructions.md §4` — `errors[]` schema (signatures map to Status via the legacy table above).
+- `bootstrap-status-format.instructions.md` — the artifact that uses this vocabulary most prominently.
+- `deferred-retry-on-workiq-fail.instructions.md` — `deferred` status semantics.
+- `scope-boundaries.instructions.md` — `blocked-config` rules.

package/plugin/instructions/workiq-only.instructions.md

@@ -48,7 +48,7 @@ For every M365 source in scope:
 
 ## Canonical WorkIQ commands (CODIFIED — do not re-discover)
 
-The CLI is at `<USER_HOME>\.kushi\bin\workiq.cmd` (resolved from `<workspace>/.kushi/config/user/project-evidence.yml workiq.cli_path`; fall back to PATH; fall back to `~/.kushi/bin/workiq.cmd`).
+The CLI is resolved in this order: `<workspace>/.kushi/config/user/project-evidence.yml workiq.cli_path` → `Get-Command workiq` (PATH) → `~/.copilot/bin/workiq[.cmd]` (Clawpilot-managed convenience fallback, probed only if it already exists). The legacy `~/.kushi/bin/workiq.cmd` path was removed in v4.4.4 — see the `setup` skill for the functional verification flow.
 
 Invocation shape:
 
@@ -153,7 +153,7 @@ List my Teams meetings between <YYYY-MM-DD> and <YYYY-MM-DD> where the subject c
 
 Before the first WorkIQ query in a run:
 
-1. Resolve CLI path: `<workspace>/.kushi/config/user/project-evidence.yml workiq.cli_path` → `Get-Command workiq` → `~/.kushi/bin/workiq.cmd`. If none resolves → log `workiq-not-on-path`, write evidence file pointing at install docs, STOP this source.
+1. Resolve CLI path: `<workspace>/.kushi/config/user/project-evidence.yml workiq.cli_path` → `Get-Command workiq` → `~/.copilot/bin/workiq[.cmd]` (Clawpilot-managed, only if present). If none resolves → log `workiq-not-on-path`, write evidence file pointing at install docs, STOP this source. The legacy `~/.kushi/bin/workiq.cmd` probe was removed in v4.4.4; the `setup` skill handles the recovery flow.
 2. Probe with `workiq ask -q "ping"`. If EULA prompt → `workiq accept-eula` once, retry.
 3. Capture `--version` once into run-log for audit.
 

package/plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kushi",
   "description": "Multi-source project evidence + Q&A agent. Snapshot + stream capture across Email, Teams, OneNote, SharePoint, Meetings, CRM, ADO; plus read-only natural-language Q&A over the captured evidence. WorkIQ-only for M365 sources (Graph / m365_* FORBIDDEN as fallbacks; user-paste is first-class). Host-agnostic. Three install profiles: core (aggregator only), standard (default — adds bootstrap/refresh + FDE authoring), full (adds State/ rollup).",
-  "version": "3.12.1",
+  "version": "3.12.2",
   "author": "ushakrishnan",
   "repository": "https://github.com/gim-home/kushi",
   "default_profile": "standard",
@@ -11,6 +11,7 @@
       "skills": [
         "intro",
         "self-check",
+        "setup",
         "pull-email",
         "pull-teams",
         "pull-meetings",
@@ -24,6 +25,7 @@
         "ask-project"
       ],
       "prompts": [
+        "setup",
         "aggregate",
         "consolidate",
         "status",
@@ -36,6 +38,7 @@
       ],
       "reference_packs": [],
       "verbs": [
+        "setup",
         "aggregate",
         "consolidate",
         "status",

package/plugin/prompts/setup.prompt.md

@@ -0,0 +1,29 @@
+---
+name: setup
+description: "Functionally verify WorkIQ is reachable + auto-fill contributor identity into project-evidence.yml. Run once per machine; idempotent."
+argument-hint: "(no args) — pings WorkIQ, captures identity, persists to ~/.kushi config"
+agent: kushi
+tools: [search, read/readFile, edit, agent]
+---
+
+## User Input
+
+```text
+(none)
+```
+
+# /setup
+
+Route to `@Kushi setup`.
+
+Runs the **setup** skill:
+
+1. Resolves the workiq CLI path (pinned `cli_path` → PATH → Clawpilot-managed `~/.copilot/bin/workiq` fallback). **No `~/.kushi/bin/` filesystem probe** (removed in v4.4.4).
+2. Functionally verifies WorkIQ by sending: *"Who am I? Return UPN, displayName, mailNickname as JSON."*
+3. Parses the response and writes `identity` (alias / display_name / email) into `<workspace>/.kushi/config/user/project-evidence.yml`, preserving comments.
+4. On failure, walks the user through install / sign-in / retry using `ask_user` (no outbound sends).
+5. Prints a green status table summarizing host, cli_path, identity, and persistence target.
+
+**Idempotent.** Re-running on a healthy machine re-verifies the connection and exits cleanly — bootstrap / refresh are blocked until this skill records `identity_status: verified`.
+
+Delegates to `setup` skill.

package/plugin/skills/bootstrap-project/SKILL.md

@@ -61,11 +61,7 @@ Hard stop if WorkIQ returns auth error or empty — print the WorkIQ sign-in hin
 Verify in order. Stop on hard failures.
 
 1. **OS + host runtime** — display OS + Node/PowerShell version. Informational.
-2. **WorkIQ install (REQUIRED, hard stop)** — read `<workspace>/.kushi/config/user/project-evidence.yml workiq.cli_path`. If missing, probe known paths:
-   - `$HOME\.kushi\bin\workiq.cmd`
-   - `$env:LOCALAPPDATA\Programs\WorkIQ\workiq.cmd`
-   - `$env:ProgramFiles\WorkIQ\workiq.cmd`
-   If found, persist path. If not found, ask user for path (or to install). Test with `<workiq.cli_path> --help`. Without WorkIQ, M365 sources will all fail — STOP.
+2. **WorkIQ install (REQUIRED, hard stop)** — read `<workspace>/.kushi/config/user/project-evidence.yml workiq.cli_path`. If missing, dispatch the `setup` skill (which does a functional `workiq ask -q "Who am I?"` check, captures identity, and walks the user through install/sign-in on failure). **Do NOT probe `$HOME\.kushi\bin\` — removed in v4.4.4** because it triggered VS Code's "Allow reading external directory?" prompt even on machines where workiq was already on PATH. If `setup` returns `identity_status: skipped-*`, STOP — bootstrap is blocked until WorkIQ is reachable.
 3. **Conditional az login** — only if `<workspace>/.kushi/config/shared/integrations.yml` OR `<workspace>/.kushi/config/shared/integrations.yml` exists. Per `az-auth-conditional.instructions.md`. Soft warning on failure, never blocking.
 4. **Engagement-root resolution** — per `engagement-root-resolution.instructions.md`. Persist to `<workspace>/.kushi/config/user/project-evidence.yml engagement_root` if newly resolved.
 

package/plugin/skills/pull-ado/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "pull-ado"
-version: "2.3.1"
+version: "2.3.2"
 description: "Pull ADO evidence as an engagement TREE (parent Engagement + every child WI). Per-item discussion comments + revision history (verbatim). Deterministic resolution; no parent-only summaries. Per ado-engagement-tree.instructions.md."
 ---
 
@@ -40,23 +40,37 @@ WorkIQ-first per `workiq-first.instructions.md` — but **for ADO, REST is prefe
 
 ## Hard prerequisites (REQUIRED — see `scope-boundaries.instructions.md` Rule 3)
 
-This skill is **HARD-fail** without both:
+This skill is **HARD-fail** without ALL of the following (effective-config rule):
 
-1. Global config: `<workspace>/.kushi/config/shared/integrations.yml` exists with non-placeholder `organization` AND `defaultProject`.
-2. Per-project boundary: `<engagement-root>/<project>/integrations.yml#boundaries.ado.area_paths` is non-empty (OR `boundaries.ado.work_item_ids` is pinned).
+1. A resolvable `organization` from EITHER:
+   - per-project override: `<engagement-root>/<project>/integrations.yml#sources.ado.organization_override`, OR
+   - global default: `<workspace>/.kushi/config/shared/integrations.yml#ado.organization` (non-placeholder).
+2. A resolvable `defaultProject` from EITHER:
+   - per-project override: `<engagement-root>/<project>/integrations.yml#sources.ado.project_override`, OR
+   - global default: `<workspace>/.kushi/config/shared/integrations.yml#ado.project` (non-placeholder).
+3. Per-project boundary: `<engagement-root>/<project>/integrations.yml#boundaries.ado.area_paths` is non-empty OR `boundaries.ado.work_item_ids` is pinned OR `sources.ado.engagement_id` is pinned (pinned WI IDs are sufficient — they bypass area-path discovery).
 
-If either is missing, refuse with the exact message:
+**Resolution order at runtime:**
+```
+effective.organization = project.sources.ado.organization_override ?? global.ado.organization
+effective.project      = project.sources.ado.project_override      ?? global.ado.project
+effective.tenant_id    = project.sources.ado.tenant_id_override    ?? global.ado.tenant_id
+```
+
+If any required value resolves to null/placeholder, refuse with:
 
 ```
-ado-config-missing — drop a filled config.yml at
-<workspace>/.kushi/config/shared/integrations.yml. See template at
-plugin/templates/init/integrations.template.yml (ado: block). Then add boundaries.ado.area_paths
-to <project>/integrations.yml.
+ado-config-missing — fill the ado: block in
+<workspace>/.kushi/config/shared/integrations.yml, OR set the corresponding
+sources.ado.*_override in <project>/integrations.yml. Then ensure
+boundaries.ado.area_paths (or work_item_ids, or sources.ado.engagement_id)
+is pinned.
 ```
 
 Discovery loops (`title_contains`, `tags_contains`, `custom_iscrm_id`) are still
 permitted — but ONLY inside `boundaries.ado.area_paths`. There is no
-tenant-wide title-fuzzy scan in v3.7.0+.
+tenant-wide title-fuzzy scan in v3.7.0+. If `sources.ado.engagement_id` is
+already pinned, skip discovery entirely and proceed to Step 2 (tree expansion).
 
 ## Auth (deterministic, no improvisation)
 

package/plugin/skills/pull-crm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "pull-crm"
-version: "2.3.1"
+version: "2.3.2"
 description: "Pull CRM (Dataverse) evidence (snapshot: engagement record VERBATIM long-text fields + ALL annotations with formatted values; stream: notes/activities/status changes). Per-record explicit $select + formatted-value annotations. FDE entity sets use crm-field-manifest.md. v2.3.0: exhaustive 4-step resolution sequence (title → account[s] → wide-text → recent-slice → ask). Anti-patterns codified: no statecode filter, new_companyname is NOT a field, never disable from one shallow probe."
 ---
 
@@ -38,20 +38,31 @@ WorkIQ-first per `workiq-first.instructions.md`. Thoroughness per `evidence-thor
 
 ## Hard prerequisites (REQUIRED — see `scope-boundaries.instructions.md` Rule 3)
 
-This skill is **HARD-fail** without both:
+This skill is **HARD-fail** without BOTH (effective-config rule):
 
-1. Global config: `<workspace>/.kushi/config/shared/integrations.yml` exists with non-placeholder `environmentUrl`.
+1. A resolvable Dataverse `environment_url` from EITHER:
+   - per-project override: `<engagement-root>/<project>/integrations.yml#sources.crm.environment_url_override` (preferred — survives global config drift), OR
+   - global default: `<workspace>/.kushi/config/shared/integrations.yml#crm.environment_url` (non-placeholder).
 2. Per-project boundary: `<engagement-root>/<project>/integrations.yml#boundaries.crm.record_ids` OR `boundaries.crm.request_ids` is non-empty.
 
-If either is missing, refuse with the exact message:
+**Resolution order at runtime:**
+```
+effective.environment_url = project.sources.crm.environment_url_override ?? global.crm.environment_url
+effective.entity_set      = project.sources.crm.entity_set_override     ?? global.crm.default_entity_set
+effective.tenant_id       = project.sources.crm.tenant_id_override      ?? global.crm.tenant_id
+```
+
+If `effective.environment_url` is null/placeholder, refuse with:
 
 ```
 crm-config-missing — drop a filled config.yml at
-<workspace>/.kushi/config/shared/integrations.yml. See template at
-plugin/templates/init/integrations.template.yml (crm: block). Then add boundaries.crm.record_ids
-(or request_ids) to <project>/integrations.yml.
+<workspace>/.kushi/config/shared/integrations.yml (crm: block), OR set
+sources.crm.environment_url_override in <project>/integrations.yml.
+Then ensure boundaries.crm.record_ids (or request_ids) is non-empty.
 ```
 
+If `effective.environment_url` resolves but `boundaries.crm.record_ids` AND `boundaries.crm.request_ids` are both empty, refuse with the analogous `crm-boundary-missing` message.
+
 **No "narrate from email" fallback exists in v3.7.0+.** CRM evidence comes from CRM
 or it is absent — Coverage Notes will say so explicitly. Synthesis across sources
 happens at consolidation, not at pull.

package/plugin/skills/setup/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: "setup"
+version: "1.0.0"
+description: "First-run machine setup for Kushi. Functionally verifies WorkIQ is reachable by sending a real query, captures contributor identity (alias / display_name / email) from the response, persists it to `<workspace>/.kushi/config/user/project-evidence.yml`, and walks the user through workiq install/start if it is not running. Idempotent — re-running on a healthy machine prints a green status table and exits. Modeled on the wss-cto-write-connect `setup.agent.md` Step 6 pattern: ping the service, ask the user nothing the service can already answer."
+---
+
+# Skill: setup
+
+> **Doctrine**: WorkIQ is a **service**, not a binary on disk. This skill probes it functionally (sends a real query) instead of probing the filesystem. Avoids the v3.x `~/.kushi/bin/` external-directory prompt and the dead-config UX where `<auto>` placeholders surface to the user.
+>
+> **No outbound messages.** This skill never sends Teams / email / RSVP. Identity capture only writes the local YAML.
+>
+> **Idempotent.** Re-running on a machine where everything is healthy prints the green status table and exits cleanly. Safe to wire into `bootstrap-project` Step 1.
+
+Run this skill when:
+
+- The user says `setup`, `kushi setup`, `verify workiq`, `who am I to kushi`, `fix my install`, `setup kushi`.
+- The installer finished and printed `Run \`setup\` once to verify WorkIQ + auto-fill identity`.
+- A `pull-*` or `bootstrap-project` skill is about to fire its first WorkIQ query in a workspace whose `project-evidence.yml#identity` is still `<auto>` / missing.
+
+## What it does
+
+1. Detects the host runtime + workiq.cli_path (no filesystem probes beyond an explicit `cli_path`).
+2. **Functionally verifies WorkIQ** by sending one query: *"Who am I? Return UPN, displayName, mailNickname as JSON."*
+3. On success, persists the captured identity to `<workspace>/.kushi/config/user/project-evidence.yml#identity` (preserving comments + other keys).
+4. On failure, walks the user through starting WorkIQ via the host's documented entry point, then retries.
+5. Prints a final status table the user can screenshot to file with IT support.
+
+## Inputs
+
+None. The skill discovers everything it needs.
+
+Optional flags surfaced by the user:
+- `non-interactive` / `--yes` — skip `ask_user` retries on failure; emit a single actionable error and exit.
+- `verbose` — print every probe step + raw workiq response.
+
+## Steps
+
+### Step 1 — Detect host runtime (informational)
+
+Run `node --version`, `pwsh --version` (or `powershell -Command "$PSVersionTable.PSVersion"`), and capture the platform (`win32` / `darwin` / `linux`). Display:
+
+```
+🔍 Host: <platform> · Node <ver> · PowerShell <ver>
+```
+
+Never blocking. Used only for the final status table.
+
+### Step 2 — Resolve workiq CLI path (NO filesystem probe beyond explicit cli_path)
+
+Resolution order (FIRST match wins):
+
+1. **Explicit pin** — read `<workspace>/.kushi/config/user/project-evidence.yml#workiq.cli_path`. If present and the file exists on disk, use it.
+2. **PATH lookup** — run `Get-Command workiq -ErrorAction SilentlyContinue` (Windows) / `command -v workiq` (Unix). If a result is returned, use the first executable hit.
+3. **Host integration** — if the host is Clawpilot and `~/.copilot/bin/workiq[.cmd]` exists (this is the Clawpilot-managed location, not a kushi-managed location), use it as a final convenience fallback. **Do NOT probe `~/.kushi/bin/` — that path is removed from kushi doctrine as of v4.4.4.**
+
+If none of the three resolves, jump to **Step 4 — Recovery prompt** with reason `cli-not-resolved`.
+
+### Step 3 — Functional verification (the actual check)
+
+Send this exact query (PowerShell shape — adapt single-quoting for bash):
+
+```powershell
+& "<resolved-cli-path>" ask -q 'Who am I? Return UPN, displayName, mailNickname strictly as a single JSON object with keys upn, displayName, mailNickname. No prose, no markdown fences.' 2>&1
+```
+
+Timeout: 30 seconds. Capture both stdout and stderr.
+
+**Parse the response.** Look for a JSON object containing all three keys. Strip any leading `request-id:` line that WorkIQ prepends. If WorkIQ wrapped the JSON in markdown fences (```json ... ```), strip them.
+
+| Outcome | Next |
+|---|---|
+| Valid JSON with non-empty `upn`, `displayName`, `mailNickname` | Go to Step 5 (persist identity) |
+| WorkIQ returned a summary / refusal / empty | Retry ONCE with stricter prompt: *"Output ONLY the JSON object, nothing else. Do not narrate, do not explain. {upn, displayName, mailNickname}."* If still no JSON, jump to Step 4 with reason `workiq-no-identity`. |
+| Process timed out | Step 4 with reason `workiq-timeout` |
+| Non-zero exit (auth error, ENOENT, etc.) | Step 4 with reason `workiq-exit-<code>` |
+
+### Step 4 — Recovery prompt (only on Step-2 or Step-3 failure)
+
+Display the platform-appropriate install/start block. Use `ask_user` to drive the recovery loop.
+
+**Recovery messages by reason:**
+
+```
+cli-not-resolved (Windows)
+⚙️  WorkIQ CLI not found.
+
+Kushi could not locate the workiq executable in:
+  - <workspace>/.kushi/config/user/project-evidence.yml#workiq.cli_path  (unset or path missing)
+  - the system PATH                                                       (no `workiq` on PATH)
+  - ~/.copilot/bin/workiq.cmd                                             (Clawpilot-managed fallback; not present)
+
+To install / start WorkIQ:
+  1. Open a NEW terminal window (keep this one open).
+  2. Run:  winget install Microsoft.WorkIQ
+     (macOS:  brew install --cask microsoft-workiq)
+  3. After install completes, run:  workiq accept-eula
+  4. Then run:  workiq ask -q "ping"   — should print a non-empty response.
+  5. Come back to this window when done.
+```
+
+```
+workiq-no-identity / workiq-timeout / workiq-exit-*
+⚙️  WorkIQ is installed but did not respond to the identity query.
+
+Likely causes (in priority order):
+  1. Not signed in. Run:           workiq ask -q "ping"
+                                   (You'll be prompted to sign in on first call.)
+  2. Off-corpnet / VPN required.   Reconnect and retry.
+  3. WorkIQ daemon not running.    (Host-specific. Clawpilot users: restart Clawpilot.
+                                   VS Code Chat users: restart the workiq host process.)
+  4. Tenant misconfiguration.      Check the configured tenant in your WorkIQ profile.
+
+When ready, type 'retry' below.
+```
+
+`ask_user` choices:
+
+- `retry` — re-run Step 3.
+- `change-path` — prompt for an absolute path. Validate the file exists, persist to `project-evidence.yml#workiq.cli_path`, then re-run Step 2 → Step 3.
+- `skip` — write a stub identity (`alias: 'unknown'`, `display_name: '(WorkIQ unreachable)'`, `email: 'unknown@unknown'`) AND mark `<workspace>/.kushi/config/user/project-evidence.yml#identity_status: "skipped-workiq-down"`. **bootstrap / refresh MUST refuse to run while `identity_status: skipped-*` is set**, surfacing "Run `setup` first" as the gate.
+
+Recovery loop budget: **3 retries**. After the third failure, force `skip` mode and exit cleanly. Never crash — the user still has read-only verbs available.
+
+### Step 5 — Persist identity (success path)
+
+Open `<workspace>/.kushi/config/user/project-evidence.yml`. If the file does not exist, create it from `templates/init/project-evidence.template.yml`. Update the `identity:` block in place (preserve every other key + every comment) using a YAML-comment-safe rewrite. Map:
+
+| WorkIQ field | YAML field | Notes |
+|---|---|---|
+| `upn` | `identity.email` | Verbatim. |
+| `displayName` | `identity.display_name` | Verbatim. |
+| `mailNickname` | `identity.alias` | Lowercase. Fallback to `email.split('@')[0]` if missing. |
+
+Also write:
+
+- `identity_status: "verified"` (so bootstrap/refresh stop pestering)
+- `identity_verified_at: "<ISO-8601 UTC>"`
+- `workiq.cli_path: "<resolved-path>"` (only if it was discovered via PATH or host-integration and not yet pinned)
+
+### Step 6 — Print status table
+
+```
+WorkIQ Setup Complete
+─────────────────────
+  ✅ Host:           win32 · Node v22.x · PowerShell 7.x
+  ✅ workiq.cli_path C:\Users\<you>\.copilot\bin\workiq.cmd
+  ✅ Identity        Usha Krishnan <ushak@microsoft.com> (alias=ushak)
+  ✅ Persisted to    <workspace>/.kushi/config/user/project-evidence.yml
+
+Next:   kushi bootstrap <project>      to bootstrap a project
+        kushi refresh   <project>      to refresh evidence
+```
+
+If recovery ended in `skip`, change the trailing lines to:
+
+```
+  ⚠️  WorkIQ unreachable. Identity not verified.
+       Re-run `setup` once WorkIQ is running. bootstrap / refresh are blocked
+       until then; `ask`, `status`, and Q&A verbs remain available.
+```
+
+## Notes
+
+- This skill writes ONLY to `<workspace>/.kushi/config/user/project-evidence.yml`. It does NOT touch `shared/integrations.yml` (team-owned) or any project-level file.
+- The functional check replaces the pre-v4.4.4 filesystem-probe pattern in `check-workiq.mjs` + `bootstrap-project SKILL.md` Step 1.2. Those still ship for backwards-compat at install time but are no longer the source of truth for "is WorkIQ healthy."
+- See `instructions/identity-resolution.instructions.md` for the contract this skill implements.
+
+## References
+
+- `instructions/workiq-only.instructions.md` — WorkIQ-only doctrine for M365 sources.
+- `instructions/identity-resolution.instructions.md` — contributor identity contract.
+- `instructions/communication-guidelines.instructions.md` — chat-reply tone for the recovery prompts.
+- `instructions/status-taxonomy.instructions.md` — `identity_status` value vocabulary.

package/plugin/templates/init/integrations.template.yml

@@ -1,19 +1,32 @@
-# Kushi — optional global integrations defaults.
-#
-# Seeded by the installer on first install. Never overwritten on upgrade.
-# Per-project `integrations.yml` (inside the engagement folder) always
-# takes precedence over this file.
-#
-# Most users can leave this file as-is. Fill it in only if you want a
-# default CRM / ADO configuration that applies across all projects.
-
-# Microsoft Dataverse (CRM) defaults.
-# crm:
-#   environment_url: 'https://<org>.crm.dynamics.com'
-#   tenant_id:       '72f988bf-86f1-41af-91ab-2d7cd011db47'   # Microsoft tenant
-
-# Azure DevOps defaults.
-# ado:
-#   organization: 'https://dev.azure.com/<org>'
-#   project:      '<default-project>'
-#   tenant_id:    '72f988bf-86f1-41af-91ab-2d7cd011db47'      # Microsoft tenant
+# Kushi — optional global integrations defaults.
+#
+# Seeded by the installer on first install. Never overwritten on upgrade.
+# Per-project `integrations.yml` (inside the engagement folder) always
+# takes precedence over this file. Effective-config rule:
+#   effective.X = project.override ?? global.X   (hard-fail only if both empty)
+#
+# Most users can leave this file as-is. Uncomment + edit only if you want a
+# default CRM / ADO configuration that applies across all projects.
+#
+# Microsoft (MSFT) tenant defaults shown below. If you work in the Microsoft
+# tenant (most Industry Solutions FDEs), these values are correct as-is.
+
+# Microsoft Dataverse (CRM) defaults.
+# Per-project overrides in <engagement-root>/<project>/integrations.yml under
+# sources.crm.environment_url_override / entity_set_override always take
+# precedence (e.g. FDE intake projects point at iscrm.crm.dynamics.com /
+# new_frontierengineeringtriages).
+# crm:
+#   environment_url:     'https://microsoftsales.crm.dynamics.com'
+#   tenant_id:           '72f988bf-86f1-41af-91ab-2d7cd011db47'   # Microsoft tenant
+#   default_entity_set:  'opportunities'
+#   az_resource_id:      'https://microsoftsales.crm.dynamics.com'
+
+# Azure DevOps defaults.
+# Per-project pin in <engagement-root>/<project>/integrations.yml sources.ado
+# (engagement_id, area_paths) overrides the discovery defaults here.
+# ado:
+#   organization:    'https://dev.azure.com/IndustrySolutions'
+#   project:         'IS Engagements'
+#   tenant_id:       '72f988bf-86f1-41af-91ab-2d7cd011db47'   # Microsoft tenant
+#   az_resource_id:  '499b84ac-1321-427f-aa17-267ca6975798'   # ADO well-known resource id

package/plugin/templates/init/project-evidence.template.yml

@@ -42,7 +42,11 @@ active_projects:
 # (Optional) Path to the WorkIQ CLI. If omitted, Kushi resolves in this order:
 #   1. this `cli_path` value
 #   2. `workiq` on PATH
-#   3. ~/.kushi/bin/workiq.cmd  (Windows) / ~/.kushi/bin/workiq  (Linux/macOS)
+#   3. ~/.copilot/bin/workiq[.cmd]  (Clawpilot-managed convenience fallback —
+#      probed ONLY if it already exists; never created by kushi)
+# The legacy ~/.kushi/bin/ path is no longer probed (removed in v4.4.4 to avoid
+# the VS Code "Allow reading external directory?" prompt). Run the `setup` skill
+# to functionally verify WorkIQ is reachable and auto-fill your identity.
 # workiq:
-#   cli_path: 'C:\Users\<you>\.kushi\bin\workiq.cmd'
+#   cli_path: 'C:\Program Files\WorkIQ\workiq.cmd'
 

package/src/check-workiq.mjs

@@ -6,10 +6,17 @@ import os from 'node:os';
 /**
  * Probe for a working WorkIQ install.
  *
- * Resolution order:
+ * Resolution order (NO kushi-owned filesystem probe — see v4.4.4 doctrine):
  *   1. explicit absolute path supplied via --workiq-path / opts.workiqPath
  *   2. `workiq` on PATH (via `where` on Windows, `command -v` elsewhere)
- *   3. Kushi-managed bin: ~/.kushi/bin/workiq.cmd (Win) or ~/.kushi/bin/workiq
+ *   3. Clawpilot-managed convenience fallback: ~/.copilot/bin/workiq[.cmd]
+ *      (only probed when it ALREADY exists — never created, never assumed)
+ *
+ * The old `~/.kushi/bin/workiq.cmd` probe was removed in v4.4.4: it caused
+ * VS Code to surface an "Allow reading external directory?" prompt for `bin`
+ * even on machines where workiq was already discoverable via PATH. The
+ * functional verification now happens in the `setup` skill via a real
+ * `workiq ask -q "Who am I?"` call, not a filesystem probe.
  *
  * Returns:
  *   { ok: true,  path, version }                       — usable WorkIQ found
@@ -19,16 +26,9 @@ import os from 'node:os';
  *   'not-found'        — no workiq binary anywhere we looked
  *   'path-invalid'     — explicit --workiq-path was given but the file doesn't exist
  *   'not-executable'   — found but `--version` failed (corrupt install, missing deps, etc.)
+ *   'not-responsive'   — runs `--version` ok but functional ping returned no JSON-shaped output
  */
 export function checkWorkIQ(opts = {}) {
-  const isWin = process.platform === 'win32';
-  const homeBin = path.join(
-    os.homedir(),
-    '.kushi',
-    'bin',
-    isWin ? 'workiq.cmd' : 'workiq',
-  );
-
   if (opts.workiqPath) {
     const abs = path.resolve(opts.workiqPath);
     if (!existsSync(abs) || !statSync(abs).isFile()) {
@@ -44,9 +44,8 @@ export function checkWorkIQ(opts = {}) {
   const onPath = findOnPath('workiq');
   if (onPath) return runVersion(onPath);
 
-  if (existsSync(homeBin) && statSync(homeBin).isFile()) {
-    return runVersion(homeBin);
-  }
+  const clawpilotBin = clawpilotManagedBin();
+  if (clawpilotBin) return runVersion(clawpilotBin);
 
   return {
     ok: false,
@@ -55,6 +54,27 @@ export function checkWorkIQ(opts = {}) {
   };
 }
 
+/**
+ * Clawpilot installs workiq at ~/.copilot/bin/workiq[.cmd] as part of its own
+ * setup. We probe it ONLY if it already exists — we never create the dir, and
+ * we never probe `~/.kushi/bin/` (the v3.x location, removed in v4.4.4).
+ */
+function clawpilotManagedBin() {
+  const isWin = process.platform === 'win32';
+  const candidate = path.join(
+    os.homedir(),
+    '.copilot',
+    'bin',
+    isWin ? 'workiq.cmd' : 'workiq',
+  );
+  try {
+    if (existsSync(candidate) && statSync(candidate).isFile()) return candidate;
+  } catch {
+    // permission denied / external-dir prompt declined — treat as not present
+  }
+  return null;
+}
+
 function findOnPath(name) {
   const isWin = process.platform === 'win32';
   const cmd = isWin ? 'where' : 'command';
@@ -106,13 +126,54 @@ function runVersion(binPath) {
   return { ok: true, path: binPath, version };
 }
 
+/**
+ * Functional check — sends a real `workiq ask -q "ping"` and confirms a
+ * non-empty response. Used by the installer's preflight AFTER runVersion()
+ * passes, so we don't ship users to bootstrap with a workiq binary that
+ * exists but can't actually answer queries (sign-in missing, daemon down,
+ * tenant misconfigured, etc.).
+ *
+ * Returns the same shape as runVersion(). On a soft failure we still return
+ * { ok: true } and just attach `.warning` so the installer can print a hint
+ * without hard-failing — the `setup` skill is responsible for the deep
+ * recovery flow.
+ */
+export function pingWorkIQ(binPath, { timeoutMs = 30_000 } = {}) {
+  const isWin = process.platform === 'win32';
+  const res = isWin
+    ? spawnSync(`"${binPath}" ask -q "ping"`, {
+        encoding: 'utf-8',
+        timeout: timeoutMs,
+        shell: true,
+      })
+    : spawnSync(binPath, ['ask', '-q', 'ping'], {
+        encoding: 'utf-8',
+        timeout: timeoutMs,
+      });
+  const stdout = (res.stdout || '').trim();
+  const stderr = (res.stderr || '').trim();
+  if (res.status !== 0) {
+    return {
+      ok: true,
+      warning: `workiq ping returned exit ${res.status}. Run \`workiq ask -q "ping"\` manually to confirm sign-in. (${stderr.split(/\r?\n/)[0] || 'no stderr'})`,
+    };
+  }
+  if (!stdout) {
+    return {
+      ok: true,
+      warning: 'workiq ping returned empty stdout. The CLI is reachable but may not be signed in. Run `workiq ask -q "ping"` manually.',
+    };
+  }
+  return { ok: true };
+}
+
 function installHint() {
   const plat = process.platform;
   if (plat === 'win32') {
-    return 'Install with: winget install Microsoft.WorkIQ';
+    return 'Install with: winget install Microsoft.WorkIQ — then run `workiq ask -q "ping"` to sign in.';
   }
   if (plat === 'darwin') {
-    return 'Install with: brew install --cask microsoft-workiq';
+    return 'Install with: brew install --cask microsoft-workiq — then run `workiq ask -q "ping"` to sign in.';
   }
   return 'See https://gim-home.github.io/kushi/getting-started/install-workiq/ for Linux instructions.';
 }

package/src/main.mjs

@@ -12,12 +12,11 @@ import {
   PLUGIN_SOURCE_DIR,
   PROJECT_MARKERS,
 } from './constants.mjs';
-import { promptForDestination } from './prompt.mjs';
 import { copyAssets } from './copy-assets.mjs';
 import { mergeSettings } from './settings.mjs';
 import { mergeCopilotInstructions } from './copilot-instructions.mjs';
 import { seedConfig } from './seed-config.mjs';
-import { checkWorkIQ, tryInstallWorkIQ } from './check-workiq.mjs';
+import { checkWorkIQ, pingWorkIQ, tryInstallWorkIQ } from './check-workiq.mjs';
 import {
   resolveProfile,
   makeIncludeFilter,
@@ -92,32 +91,7 @@ async function installVscode(options, resolved, version) {
     warnIfNotProjectRoot(projectRoot);
   }
 
-  let dest;
-  if (options.dest) {
-    dest = options.dest.replace(/\\/g, '/');
-    if (path.isAbsolute(dest)) {
-      console.error('\n  Please use a relative path (e.g., .kushi).\n');
-      process.exit(1);
-    }
-    dest = dest.replace(/\/+$/, '');
-    if (!dest) {
-      console.error('\n  Please provide a non-empty destination path.\n');
-      process.exit(1);
-    }
-    const resolvedPath = path.resolve(projectRoot, dest);
-    if (
-      !resolvedPath.startsWith(projectRoot + path.sep) &&
-      resolvedPath !== projectRoot
-    ) {
-      console.error('\n  Destination must be within the current project.\n');
-      process.exit(1);
-    }
-  } else if (options.yes) {
-    dest = DEFAULT_DEST;
-  } else {
-    dest = await promptForDestination(DEFAULT_DEST);
-  }
-
+  const dest = DEFAULT_DEST;
   const fullDest = path.resolve(projectRoot, dest);
   await confirmOverwriteIfExists(fullDest, dest, options.force);
 
@@ -182,9 +156,7 @@ async function installVscode(options, resolved, version) {
  */
 async function installClawpilot(options, resolved, version) {
   const home = os.homedir();
-  const fullDest = options.dest
-    ? path.resolve(options.dest)
-    : path.join(home, ...CLAWPILOT_DEST_SUBPATH.split('/'));
+  const fullDest = path.join(home, ...CLAWPILOT_DEST_SUBPATH.split('/'));
 
   const displayDest = fullDest.startsWith(home + path.sep)
     ? '~' + path.sep + path.relative(home, fullDest)
@@ -345,7 +317,16 @@ async function preflightWorkIQ(options) {
     process.exit(1);
   }
 
-  console.log(`  ✓ WorkIQ detected at ${result.path} (${result.version})\n`);
+  console.log(`  ✓ WorkIQ detected at ${result.path} (${result.version})`);
+
+  // Functional ping — confirm the binary actually answers queries, not just
+  // that it exists. Soft warning only; the `setup` skill does the deep
+  // recovery + identity capture on first verb run.
+  const ping = pingWorkIQ(result.path);
+  if (ping.warning) {
+    console.warn(`    ⚠  ${ping.warning}`);
+  }
+  console.log('    Next: run `setup` once to verify sign-in + auto-fill your identity.\n');
 }
 
 /**

package/src/prompt.mjs

@@ -1,42 +0,0 @@
-import { createInterface } from 'node:readline/promises';
-import path from 'node:path';
-
-/**
- * Prompt the user for a destination directory.
- * @param {string} defaultDest
- * @returns {Promise<string>}
- */
-export async function promptForDestination(defaultDest) {
-  const { stdin: input, stdout: output } = await import('node:process');
-  const rl = createInterface({ input, output });
-
-  rl.on('close', () => {});
-
-  let dest;
-  try {
-    const answer = await rl.question(
-      `  Where should Kushi assets be installed? (${defaultDest}): `,
-    );
-    dest = answer.trim() || defaultDest;
-  } catch {
-    process.exit(0);
-  } finally {
-    rl.close();
-  }
-
-  return validatePath(dest);
-}
-
-function validatePath(raw) {
-  if (path.isAbsolute(raw)) {
-    console.error('\n  Please use a relative path (e.g., .kushi).\n');
-    process.exit(1);
-  }
-  const resolved = path.resolve(process.cwd(), raw);
-  const root = process.cwd();
-  if (!resolved.startsWith(root + path.sep) && resolved !== root) {
-    console.error('\n  Destination must be within the current project.\n');
-    process.exit(1);
-  }
-  return raw.replace(/\\/g, '/').replace(/\/+$/, '');
-}