@lsctech/polaris 0.3.22 → 0.3.23

package/dist/workspace/.polaris/skills/polaris-analyze/chain.md

@@ -16,7 +16,7 @@ Query runtime state before acting. Do not infer analysis scope or prior progress
 Always use the repo-local Polaris CLI:
 
 ```
-npm run polaris -- <command>
+polaris <command>
 ```
 
 Never assume a globally linked `polaris` command exists.
@@ -69,7 +69,7 @@ Telemetry file: `.taskchain_artifacts/polaris-analyze/runs/<run-id>/telemetry.js
 |---|---|---|
 | `run-start` | agent | 01 — before any Linear access |
 | `step-complete` | agent | end of every step |
-| `loop-aborted` | `npm run polaris -- loop abort` | any blocker halt |
+| `loop-aborted` | `polaris loop abort` | any blocker halt |
 
 Required fields on every event: `event`, `run_id`, `timestamp`.
 

package/dist/workspace/.polaris/skills/polaris-analyze/issue-reconciliation.md

@@ -142,7 +142,7 @@ After updating issue bodies, verify the reconciled issues are packet-actionable:
 
 ```bash
 # Dry-run a polaris-run to check all preflight gates pass
-npm run polaris -- loop dispatch --dry-run <cluster-id>
+polaris loop dispatch --dry-run <cluster-id>
 ```
 
 All children should pass body and scope preflight gates. If any fail,

package/dist/workspace/.polaris/skills/polaris-analyze/linked-skills/repo-analysis.md

@@ -19,7 +19,7 @@ version: "1.0"
 
 Provide targeted code intelligence when polaris-analyze needs to understand the affected code surface.
 
-This linked-skill governs use of the configured repo-analysis provider (e.g., GitNexus). If no provider is available, the fallback path (polaris map query + ripgrep + direct file inspection) is authoritative. See `docs/Polaris/spec/provider-capabilities.md` for the full provider model.
+This linked-skill governs repository code-intelligence for polaris-analyze. The primary path is Polaris-native: `polaris graph query`, `polaris graph impact`, and `polaris map query`. If the Polaris graph is unavailable or stale, fall back to `rg` (ripgrep) plus direct file inspection. See `docs/Polaris/spec/provider-capabilities.md` for the full provider model.
 
 ---
 
@@ -44,9 +44,8 @@ This linked-skill governs use of the configured repo-analysis provider (e.g., Gi
 
 ## Provider detection
 
-At step 01, check `polaris.config.json` for `providers.repoAnalysis.preferred`.
-If a provider is configured and available in the session environment: use it.
-If unavailable or not configured: note `repo_analysis_status: not-configured` in artifact and proceed with fallback.
+At step 01, attempt `polaris graph query` to orient to the code surface. If the graph index is current, use it as primary.
+If the graph is unavailable or returns stale results: note `repo_analysis_status: graph-unavailable` in artifact and proceed with `rg` + direct inspection fallback.
 
 ---
 

package/dist/workspace/.polaris/skills/polaris-analyze/steps/02-map-affected-code.md

@@ -36,11 +36,11 @@ stop_rules:
 1. Check `repo_analysis_status` from the step 01 artifact.
 2. **If provider is available:** use it for targeted inspection only — query concepts relevant to the issue scope. Use impact analysis and context queries for specific symbols mentioned in the issue. Do not summarize the whole repo.
 3. **If provider is unavailable (fallback path):**
-   - Use `npm run polaris -- map query <path>` for route/domain/taskchain context on affected files
+   - Use `polaris map query <path>` for route/domain/taskchain context on affected files
    - Use `rg <symbol>` for symbol and pattern location across the repo
    - Use direct file inspection for implementation details
    - The fallback path is always sufficient to complete the analysis.
-4. Always run `npm run polaris -- map query <path>` for each affected file — it provides Polaris-specific routing context regardless of whether a provider is also in use.
+4. Always run `polaris map query <path>` for each affected file — it provides Polaris-specific routing context regardless of whether a provider is also in use.
 5. Inspect only files relevant to the issue scope.
 6. Record the files and execution flows inspected.
 

package/dist/workspace/.polaris/skills/polaris-catalog/SKILL.md

@@ -11,7 +11,7 @@ role: librarian
 Run the following command:
 
 ```bash
-npm run polaris -- skill packet catalog
+polaris skill packet catalog
 ```
 
 - Do not begin work until a packet is returned.
@@ -56,16 +56,16 @@ The `packet.unattended` flag controls which low-confidence behavior applies.
 - Read packet-specified folders and their POLARIS.md and SUMMARY.md files
 - Write POLARIS.md and SUMMARY.md files within `packet.allowed_write_paths`
 - Read `smartdocs/raw/` to enumerate documents for classification
-- Call `npm run polaris -- docs ingest --file <path>` to place classified documents
-- Call `npm run polaris -- doctrine draft <path>` for doctrine candidates
-- Call `npm run polaris -- map update --changed` after batch placement
+- Call `polaris docs ingest --file <path>` to place classified documents
+- Call `polaris doctrine draft <path>` for doctrine candidates
+- Call `polaris map update --changed` after batch placement
 - Create a single sealed git commit of all cognition and doc changes
 
 ## Hard rules — what polaris-catalog must NOT do
 
 - Modify implementation source code (`src/`, tests, config)
 - Modify runtime state files outside this skill's owned artifacts (cluster-state, other skills' `.taskchain_artifacts/` state, or non-catalog telemetry)
-- Call `npm run polaris -- loop continue` or `npm run polaris -- finalize`
+- Call `polaris loop continue` or `polaris finalize`
 - Write to `packet.prohibited_write_paths`
 - Git push or create PRs
 - Auto-place low-confidence files (always leave in raw or ask)

package/dist/workspace/.polaris/skills/polaris-catalog/chain.md

@@ -29,9 +29,9 @@ Read the current step's file in `steps/` before acting. Do not read ahead.
 Always use the repo-local Polaris CLI:
 
 ```
-npm run polaris -- docs ingest --file <path>
-npm run polaris -- doctrine draft <path>
-npm run polaris -- map update --changed
+polaris docs ingest --file <path>
+polaris doctrine draft <path>
+polaris map update --changed
 ```
 
 Never assume a globally linked `polaris` command exists.

package/dist/workspace/.polaris/skills/polaris-catalog/steps/04-classify-and-place.md

@@ -57,10 +57,10 @@ Run the appropriate CLI command immediately. Do not pause for user input.
 
 ```bash
 # All classes except doctrine-candidate:
-npm run polaris -- docs ingest --file <path>
+polaris docs ingest --file <path>
 
 # doctrine-candidate:
-npm run polaris -- doctrine draft <path>
+polaris doctrine draft <path>
 ```
 
 Record in `docs_placed`.
@@ -92,7 +92,7 @@ Do not fail the run.
 Run map update:
 
 ```bash
-npm run polaris -- map update --changed
+polaris map update --changed
 ```
 
 ## Hard rules

package/dist/workspace/.polaris/skills/polaris-reconcile/SKILL.md

@@ -11,7 +11,7 @@ role: librarian
 Run the following command:
 
 ```bash
-npm run polaris -- skill packet reconcile
+polaris skill packet reconcile
 ```
 
 - Do not begin work until a packet is returned.
@@ -52,7 +52,7 @@ at cluster closeout.
 - Modify implementation source code (`src/`, tests, config)
 - Modify runtime state files outside this skill's owned artifacts (cluster-state, other skills' `.taskchain_artifacts/` state, or non-reconcile telemetry)
 - Move, ingest, classify, or promote documents
-- Call `npm run polaris -- loop continue` or `npm run polaris -- finalize`
+- Call `polaris loop continue` or `polaris finalize`
 - Write to `packet.prohibited_write_paths`
 - Git push or create PRs
 

package/dist/workspace/.polaris/skills/polaris-run/SKILL.md

@@ -30,7 +30,7 @@ here because finalization is part of the run lifecycle governed by this skill. S
 Run the following command:
 
 ```
-npm run polaris -- skill packet run
+polaris skill packet run
 ```
 
 - Do not begin work until a packet is returned.

package/dist/workspace/.polaris/skills/polaris-run/chain.md

@@ -60,7 +60,7 @@ This gate enforces the thin-parent model: the Foreman is a scheduler, not a cons
 Always use the repo-local Polaris CLI:
 
 ```
-npm run polaris -- <command>
+polaris <command>
 ```
 
 Never assume a globally linked `polaris` command exists.
@@ -86,14 +86,14 @@ At each worker return boundary (step 07), apply the CHECKPOINT gate before proce
 
 1. Accept and discard worker output except the CompactReturn JSON object — all other session content is discarded.
 2. Parse the CompactReturn JSON. If it is missing or malformed, treat as a blocker and stop.
-3. Pass the CompactReturn JSON to `npm run polaris -- loop continue` for state persistence.
+3. Pass the CompactReturn JSON to `polaris loop continue` for state persistence.
 4. Preserve the existing step order — do not reorder, skip, or repeat steps based on worker output content.
 
 ## Continuation rules
 
 After step 07 evaluates the session:
 
-- **DISPATCH (all remaining children)**: run `npm run polaris -- loop run <cluster-id>`. The runtime dispatches all eligible children serially, enforcing dispatch boundaries internally. The Foreman waits for the subprocess to exit. Progress signals are emitted as `[POLARIS] RUNNING <child-id> (N/M)` and `[POLARIS] COMPLETE <child-id> (commit: <sha>)`. No per-child CompactReturn handling or state repair is needed — the runtime owns that boundary.
+- **DISPATCH (all remaining children)**: run `polaris loop run <cluster-id>`. The runtime dispatches all eligible children serially, enforcing dispatch boundaries internally. The Foreman waits for the subprocess to exit. Progress signals are emitted as `[POLARIS] RUNNING <child-id> (N/M)` and `[POLARIS] COMPLETE <child-id> (commit: <sha>)`. No per-child CompactReturn handling or state repair is needed — the runtime owns that boundary.
 - **STOP (blocked)**: halt immediately on blocker. Report unblock condition.
 - **STOP (all-done, awaiting delivery)**: `loop run` exits when all children are done. Report branch and last commit. Provide delivery command: `Use polaris-run on <PARENT-ID>. Finalize delivery.`
 - **DELIVER**: proceed to step 08 (Closeout Librarian) only when all children are Done and the user explicitly requests delivery in this session invocation.
@@ -172,7 +172,7 @@ This is not advisory. The runtime will hard-fail with `process.exit(1)` on viola
 ### Allowed transition (only legal path)
 
 ```
-Foreman → npm run polaris -- loop run <cluster-id>
+Foreman → polaris loop run <cluster-id>
   ↓ (subprocess)
   runtime selects child
   runtime dispatches worker externally
@@ -202,14 +202,14 @@ polaris-run uses these Polaris CLI calls:
 
 | Step | Polaris call | Purpose |
 |---|---|---|
-| 07 | `npm run polaris -- loop run <cluster-id>` | Run all eligible children serially; emits `[POLARIS] RUNNING <child> (N/M)` per child and `[POLARIS] COMPLETE <child> (commit: <sha>)` on completion; exits when cluster-complete or blocked |
-| 08 | `npm run polaris -- medic packet <cluster-id>` | Generate Medic packet for failed worker result (if triage required) |
+| 07 | `polaris loop run <cluster-id>` | Run all eligible children serially; emits `[POLARIS] RUNNING <child> (N/M)` per child and `[POLARIS] COMPLETE <child> (commit: <sha>)` on completion; exits when cluster-complete or blocked |
+| 08 | `polaris medic packet <cluster-id>` | Generate Medic packet for failed worker result (if triage required) |
 | 08 | Medic subagent dispatch | Dispatch Medic; wait for sealed result; validate result before proceeding |
-| 09 | `npm run polaris -- librarian packet <cluster-id>` | Generate Closeout Librarian packet for the completed cluster |
+| 09 | `polaris librarian packet <cluster-id>` | Generate Closeout Librarian packet for the completed cluster |
 | 09 | Librarian subagent dispatch | Dispatch Closeout Librarian; wait for sealed result; validate result before proceeding |
-| 10 | `npm run polaris -- finalize` | Push branch (including librarian commit), open PR, append JSONL closeout events, archive run snapshot |
+| 10 | `polaris finalize` | Push branch (including librarian commit), open PR, append JSONL closeout events, archive run snapshot |
 
-`npm run polaris -- loop run <cluster-id>` is the standard execution command. It internally manages the dispatch→checkpoint loop for all children, emitting terse progress signals the Foreman can monitor. The Foreman does not call `loop dispatch` or `loop continue` — those boundaries are owned by `loop run`.
+`polaris loop run <cluster-id>` is the standard execution command. It internally manages the dispatch→checkpoint loop for all children, emitting terse progress signals the Foreman can monitor. The Foreman does not call `loop dispatch` or `loop continue` — those boundaries are owned by `loop run`.
 
 ## Context budget
 
@@ -239,15 +239,15 @@ Telemetry file: `.taskchain_artifacts/polaris-run/runs/<run-id>/telemetry.jsonl`
 | Event | Emitted by | Step |
 |---|---|---|
 | `run-start` | agent | 01 — before any Linear access |
-| `child-dispatched` | `npm run polaris -- loop dispatch` | 07 — when one child is accepted by the execution adapter |
+| `child-dispatched` | `polaris loop dispatch` | 07 — when one child is accepted by the execution adapter |
 | `child-complete` | parent runtime | 07 — after worker return validation and completion recording |
-| `loop-checkpoint` | `npm run polaris -- loop continue` | 07 — after each child |
-| `analyze-impl-boundary-enforced` | `npm run polaris -- loop continue` | 07 — blocker/state-repair boundary event only |
-| `loop-aborted` | `npm run polaris -- loop abort` | any blocker halt |
+| `loop-checkpoint` | `polaris loop continue` | 07 — after each child |
+| `analyze-impl-boundary-enforced` | `polaris loop continue` | 07 — blocker/state-repair boundary event only |
+| `loop-aborted` | `polaris loop abort` | any blocker halt |
 | `medic-dispatched` | parent runtime | 08 — when Medic is dispatched for failed worker |
 | `medic-complete` | parent runtime | 08 — after Medic returns sealed result |
-| `pr-opened` | `npm run polaris -- finalize` | 10 |
-| `run-complete` | `npm run polaris -- finalize` | 10 |
+| `pr-opened` | `polaris finalize` | 10 |
+| `run-complete` | `polaris finalize` | 10 |
 
 Required fields on every event: `event`, `run_id`, `timestamp`.
 
@@ -255,14 +255,14 @@ Required fields on every event: `event`, `run_id`, `timestamp`.
 
 `.taskchain_artifacts/polaris-run/current-state.json` is the sole authoritative live state surface.
 
-- Update only at explicit checkpoint boundaries via `npm run polaris -- loop continue` after worker returns, or when DISPATCH boundaries mandate bootstrapping.
+- Update only at explicit checkpoint boundaries via `polaris loop continue` after worker returns, or when DISPATCH boundaries mandate bootstrapping.
 - Parent agents must not update state inline between steps.
 - If the checkpoint fails: stop and report the persistence failure.
 
 ## Machine snapshot
 
 - **Path**: `.taskchain_artifacts/polaris-run/current-state.json`
-- **Update requirement**: only at checkpoint boundaries (via `npm run polaris -- loop continue`)
+- **Update requirement**: only at checkpoint boundaries (via `polaris loop continue`)
 - **Purpose**: fast agent resume without replaying JSONL or markdown history
 
 ## Completion rule

package/dist/workspace/.polaris/skills/polaris-run/linked-skills/repo-analysis.md

@@ -21,7 +21,7 @@ version: "1.0"
 
 Provide targeted code intelligence and impact checks when polaris-run needs repository graph context.
 
-This linked-skill governs use of the configured repo-analysis provider (e.g., GitNexus). If no provider is available, the fallback path (polaris map query + ripgrep + direct file inspection) is authoritative. See `docs/Polaris/spec/provider-capabilities.md` for the full provider model.
+This linked-skill governs repository code-intelligence for polaris-run. The primary path is Polaris-native: `polaris graph query`, `polaris graph impact`, and `polaris map query`. If the Polaris graph is unavailable or stale, fall back to `rg` (ripgrep) plus direct file inspection. See `docs/Polaris/spec/provider-capabilities.md` for the full provider model.
 
 ---
 
@@ -47,9 +47,8 @@ This linked-skill governs use of the configured repo-analysis provider (e.g., Gi
 
 ## Provider detection
 
-At step 01, check `polaris.config.json` for `providers.repoAnalysis.preferred`.
-If a provider is configured and available in the session environment: use it.
-If unavailable or not configured: note `repo_analysis_status: not-configured` in artifact and proceed with fallback.
+At step 01, attempt `polaris graph query` to orient to the code surface. If the graph index is current, use it as primary.
+If the graph is unavailable or returns stale results: note `repo_analysis_status: graph-unavailable` in artifact and proceed with `rg` + direct inspection fallback.
 
 ---
 

package/dist/workspace/.polaris/skills/polaris-run/steps/01-orient-cluster.md

@@ -24,7 +24,7 @@ allowed_routes:
 allowed_skills:
   - repo-analysis
 expected_evidence:
-  - runtime state queried via npm run polaris -- loop status
+  - runtime state queried via polaris loop status
   - run_id generated or read from prior state
   - run-start telemetry emitted
   - Linear parent and children fetched
@@ -40,7 +40,7 @@ stop_rules:
 ## Actions
 
 0. **Query runtime state**:
-   Run `npm run polaris -- loop status` to check for existing session state.
+   Run `polaris loop status` to check for existing session state.
    - **Follow-up run** (state exists and is active for this cluster): read `cluster_id` and step context from runtime output. Mint a new `run_id` in `polaris-run-<slug>-<date>-<seq>` format (see `chain.md` for format rules) — do not reuse the prior `run_id`. Set `related_run_id` to the prior `run_id` read from runtime output. Runtime state is authoritative — do not infer session context from chat history.
    - **Fresh run** (no state file, or state belongs to a different cluster): generate new `run_id` in format `polaris-run-<slug>-<date>-<seq>` (see `chain.md` for format rules). `related_run_id` is `null`.
 
@@ -74,7 +74,7 @@ stop_rules:
    - Any blockers visible at this stage
    - Execution boundary (one parent cluster, this session)
 
-6. Invoke `npm run polaris -- loop status` to confirm runtime state is consistent before advancing to the next step.
+6. Invoke `polaris loop status` to confirm runtime state is consistent before advancing to the next step.
 
 ## Artifact update
 

package/dist/workspace/.polaris/skills/polaris-run/steps/03-select-child.md

@@ -41,7 +41,7 @@ stop_rules:
    - Do not push. Do not create a PR.
 5. If clusters.json exists, use it to determine execution order and dependencies. If absent, use the child issue ordering from Linear (lowest-numbered first) as a last-resort fallback — do not improvise ordering from chat reasoning or assumptions.
 6. Verify the selected child is not blocked in Linear. If blocked:
-   - Run `npm run polaris -- loop abort "<reason>"`.
+   - Run `polaris loop abort "<reason>"`.
    - Report blocked state and halt. Do not skip to a later child.
 7. Set the selected child as `active_child`.
 

package/dist/workspace/.polaris/skills/polaris-run/steps/06-commit-and-update-linear.md

@@ -42,12 +42,12 @@ stop_rules:
    Followed by: what was done, commit hash, validation result from step 05.
 4. Mark the child Done in Linear **only if** its acceptance criteria are satisfied.
    - If criteria are not met: leave the child open, add a comment with the gap, treat as blocked.
-5. Do not run `npm run polaris -- map update --changed` per child. Map update belongs at final delivery/session end unless runtime requirements explicitly override this.
+5. Do not run `polaris map update --changed` per child. Map update belongs at final delivery/session end unless runtime requirements explicitly override this.
 
 ## Blocker escalation
 
 If the child cannot be marked Done:
-- Run `npm run polaris -- loop abort "<reason>"`.
+- Run `polaris loop abort "<reason>"`.
 - Add a comment with the unblock condition.
 - Halt. Do not continue to the next child.
 

package/dist/workspace/.polaris/skills/polaris-run/steps/07-decide-continuation.md

@@ -21,7 +21,7 @@ allowed_routes:
   - CLAUDE.md
   - .polaris/skills/polaris-run/chain.md
 expected_evidence:
-  - npm run polaris -- loop run executed
+  - polaris loop run executed
   - RUNNING <child-id> (N/M) signal emitted per child
   - COMPLETE <child-id> (commit: <sha>) signal emitted per child
   - COMPLETE (cluster-complete) or blocked exit recorded
@@ -36,7 +36,7 @@ stop_rules:
 Run the batch dispatch loop:
 
 ```bash
-npm run polaris -- loop run <cluster-id>
+polaris loop run <cluster-id>
 ```
 
 The runtime manages everything internally: child selection, packet compilation, provider dispatch
@@ -61,7 +61,7 @@ by the Foreman is needed. When `loop run` exits 0 with `cluster-complete`, proce
 If `loop run` exits non-zero:
 - Report the blocker and unblock condition from the output.
 - Do not push. Do not create a PR.
-- Resume instruction: resolve the blocker then run `npm run polaris -- loop run <cluster-id>`.
+- Resume instruction: resolve the blocker then run `polaris loop run <cluster-id>`.
 
 ### STOP (all-done, awaiting delivery)
 

package/dist/workspace/.polaris/skills/polaris-run/steps/08-closeout-librarian.md

@@ -41,7 +41,7 @@ The Foreman does NOT:
 
 Run:
 ```bash
-npm run polaris -- librarian packet <cluster-id>
+polaris librarian packet <cluster-id>
 ```
 
 This generates a `CloseoutLibrarianPacket` at:

package/dist/workspace/.polaris/skills/polaris-run/steps/08-final-delivery.md

@@ -44,9 +44,9 @@ stop_rules:
 2. Verify the working tree is clean.
 3. Run:
    ```bash
-   npm run polaris -- finalize run
+   polaris finalize run
    ```
-   `npm run polaris -- finalize run` executes the full 12-step sequence:
+   `polaris finalize run` executes the full 12-step sequence:
    - Validates the Polaris map
    - Validates `current-state.json` schema
    - Runs targeted checks

package/dist/workspace/.polaris/skills/polaris-run/steps/09-final-delivery.md

@@ -52,7 +52,7 @@ stop_rules:
 3. Verify the working tree is clean.
 4. Run:
    ```bash
-   npm run polaris -- map index && npm run polaris -- finalize run --state-file .taskchain_artifacts/polaris-run/current-state.json
+   polaris map index && polaris finalize run --state-file .taskchain_artifacts/polaris-run/current-state.json
    ```
 
    `map index` rebuilds the atlas so finalize has accurate route data. `finalize run` then executes the full finalize sequence:

package/dist/workspace/.polaris/skills/polaris-tools/README.md

@@ -25,7 +25,7 @@ npm install -g polaris
 ### Verify
 
 ```bash
-npm run polaris -- --version
+polaris --version
 ```
 
 If the binary is not found, the skill will attempt `npx --no-install polaris` as a fallback. If that also fails, the tool returns a clear error with install instructions.

package/dist/workspace/POLARIS_RULES.md

@@ -0,0 +1,169 @@
+# Polaris Rules
+
+> This file is the single shared governance source for this Polaris-managed repository.
+> Agent files (AGENTS.md, CLAUDE.md, etc.) are pointers to this file.
+> This file is SmartDocs-ignored; it is bootstrap governance, not doctrine.
+
+## Repository Overview
+
+{{REPO_OVERVIEW}}
+
+---
+
+## Temporary Worker Doctrine
+
+Every model instance is a temporary occupant of a durable role. Roles persist;
+model instances are disposable.
+
+A worker should arrive at a task knowing only:
+
+- what job it is doing
+- what files it may touch
+- what route governs the work
+- what validation proves completion
+
+If a worker requires broad repository context, the cognition structure has
+failed, not the worker.
+
+---
+
+## Repository Memory Doctrine
+
+Polaris stores institutional memory in repository artifacts rather than model
+memory. Knowledge should be discoverable through navigation, route cognition,
+SmartDocs, summaries, commits, telemetry, and runtime artifacts.
+
+Workers should not rely on persistent model memory to perform assigned work.
+
+---
+
+## Navigation Before Retrieval
+
+Links are retrieval paths, not reading assignments.
+
+Workers should not read doctrine, charts, or supporting documents merely because
+they exist.
+
+Expected behavior:
+
+1. Attempt work
+2. Encounter problem
+3. Check local guidance
+4. Match symptom
+5. Retrieve relevant artifact
+6. Continue
+
+Never preload all linked documents.
+Never load all doctrine.
+Never load all charts.
+
+Navigation precedes retrieval.
+Retrieval precedes loading.
+
+---
+
+## Skill Command Routing
+
+When a Polaris skill command is received, load the skill packet before any other
+action. Full routing table: `.polaris/skills/ROUTING.md`
+
+Recognized command forms use `<CLUSTER-ID>` as the work identifier:
+
+- `polaris-analyze <CLUSTER-ID>` / `run polaris-analyze on [issue] <CLUSTER-ID>`
+- `polaris-run <CLUSTER-ID>` / `run polaris-run on [issue] <CLUSTER-ID>`
+- `polaris-finalize` / `run polaris-finalize`
+- `polaris-status` / `run polaris-status`
+- `docs-ingest` / `run docs-ingest`
+- `docs-review` / `run docs-review`
+- `docs-triage` / `run docs-triage`
+- `polaris-reconcile <CLUSTER-ID>` / `run polaris-reconcile on [issue] <CLUSTER-ID>`
+- `polaris-catalog <CLUSTER-ID>` / `run polaris-catalog on [issue] <CLUSTER-ID>`
+
+When a recognized command is received:
+
+1. Look up the target skill in `.polaris/skills/ROUTING.md`
+2. Read `.polaris/skills/<target-skill>/SKILL.md` first — before any repo inspection
+3. Run the bootloader command to obtain the runtime packet
+4. Execute the skill's `chain.md` in strict step order
+
+---
+
+## Map-Query Rule
+
+The map is runtime infrastructure. Query results are model context.
+
+**Agents may query the map. Agents may not consume map artifacts.**
+
+Use:
+
+```sh
+polaris map query <path>
+```
+
+Never read these files directly:
+
+- `.polaris/map/file-routes.json`
+- `.polaris/map/index.json`
+- `.polaris/map/needs-review.json`
+
+These paths appear only in prohibition lists.
+
+---
+
+## Graph Navigation
+
+Polaris maintains a code-intelligence graph for this repository.
+Use Polaris graph commands as the primary code-intelligence path.
+Fall back to `rg` (ripgrep) and direct file inspection when the graph is unavailable.
+
+Primary commands:
+
+```sh
+polaris graph build
+polaris graph query <symbol-or-file>
+polaris graph impact <symbol-or-file>
+polaris map query <path>
+```
+
+Fallback (graph unavailable):
+- `rg <pattern>` for symbol and pattern search
+- Direct file inspection for structure and content
+
+Never prefer an external repo-analysis tool over Polaris graph for Polaris-managed repos.
+
+---
+
+## Tracker-Agnostic Work Intake
+
+Work identifiers are opaque to the model. Polaris is tracker-agnostic.
+
+Work may originate from Linear, GitHub, a SmartDocs spec, a local work contract,
+a manual prompt, or a future provider. The runtime resolves identifiers. The
+model does not interpret or construct cluster identifiers.
+
+---
+
+## Runtime Boundaries
+
+- Resolve execution state before beginning work
+- Follow the active cluster and child ordering
+- Execute only the currently assigned child
+- Do not expand scope outside the assigned child
+- If blocked, stop and report the unblock condition
+- Foreman orchestrates; Worker implements; Librarian reconciles
+- A provider may occupy multiple roles, but role authority does not merge
+
+---
+
+## Canon Discovery
+
+Project canon is route-local.
+
+Use:
+
+- `POLARIS.md` in the relevant route folder for operational guidance
+- `SUMMARY.md` in the relevant route folder for informational context
+- `polaris map query <path>` for route and ownership resolution
+- Runtime state artifacts for execution state and resume handling
+
+Do not assume global repository context unless explicitly provided by the runtime.

package/package.json

@@ -1,8 +1,9 @@
 {
   "name": "@lsctech/polaris",
-  "version": "0.3.22",
+  "version": "0.3.23",
   "description": "Polaris — standalone taskchain orchestration framework for governed AI agent workflows",
   "bin": {
+    "polaris": "dist/cli/index.js",
     "polaris-cli": "dist/cli/index.js"
   },
   "main": "dist/index.js",
@@ -21,7 +22,7 @@
     "node": ">=22.0.0"
   },
   "scripts": {
-    "build": "tsc && cp -r src/workspace dist/workspace",
+    "build": "tsc && rm -rf dist/workspace && cp -r src/workspace dist/workspace",
     "lint": "tsc --noEmit",
     "typecheck": "tsc --noEmit --project tsconfig.typecheck.json",
     "test": "vitest run",

package/dist/workspace/workspace/.polaris/roles/analyst.md

@@ -1,38 +0,0 @@
----
-role: analyst
-version: 1
----
-
-# Analyst Role
-
-The Analyst maps issues to code, assesses feasibility, and produces execution plans. It does not implement or dispatch workers.
-
-## Responsibilities
-
-- Fetch issue from tracker and parse scope
-- Map relevant code files for the issue
-- Assess feasibility, detect blockers
-- Produce clusters.json defining child issues
-- Write analysis documents to `smartdocs/docs/raw/`
-- Create an "Implementation" parent Linear issue and corresponding child issues.
-- Ensure the "Implementation" parent is itself a child of the issue being analyzed.
-
-## Authority Boundaries
-
-- Read: full repo (read-only)
-- Write: `smartdocs/docs/raw/`, `.polaris/clusters/<id>/clusters.json`
-- May create Linear issues: Yes
-- May implement: No
-- May dispatch: No
-
-## Prohibited Actions
-
-- Source code mutation
-- `polaris loop dispatch` or `polaris loop continue`
-- PR creation
-- Promoting docs to `specs/active/` or `doctrine/active/` (that is Librarian's role)
-
-## Escalation Rules
-
-- Blocked issue (missing dependency, unclear scope) → stop, write blocker report, do not create plan
-- Non-executable issue (already done, wrong type) → report and stop