@lsctech/polaris 0.3.22 → 0.3.23

package/dist/workspace/workspace/.polaris/skills/polaris-reconcile/chain.json

@@ -1,20 +0,0 @@
-{
-  "name": "polaris-reconcile-chain",
-  "steps": [
-    "01-orient-reconcile",
-    "02-reconcile-polaris-md",
-    "03-reconcile-summary-md",
-    "04-reconcile-commit"
-  ],
-  "terminal_steps": ["04-reconcile-commit"],
-  "scope": "cognition-only",
-  "forbidden_actions": [
-    "src file mutations",
-    "runtime state file mutations",
-    "document ingestion or promotion",
-    "polaris loop continue",
-    "polaris finalize",
-    "git push",
-    "pr creation"
-  ]
-}

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

@@ -1,67 +0,0 @@
----
-name: polaris-reconcile-chain
-description: Step order, CLI reference, canonical paths, run ID format, telemetry, and artifact authority for polaris-reconcile.
----
-
-# polaris-reconcile chain
-
-## Authority
-
-**Polaris runtime state is authoritative. Chat reasoning is not authoritative.**
-
-Query runtime state before acting. Do not infer affected folders or change scope from
-conversation context.
-
-## Step traversal order
-
-```text
-01-orient-reconcile
-02-reconcile-polaris-md
-03-reconcile-summary-md
-04-reconcile-commit
-```
-
-Read the current step's file in `steps/` before acting. Do not read ahead.
-
-## Canonical paths
-
-| State | Path |
-|---|---|
-| Skill state | `.taskchain_artifacts/polaris-reconcile/current-state.json` |
-| Telemetry | `.taskchain_artifacts/polaris-reconcile/runs/<run-id>/telemetry.jsonl` |
-
-## Run ID format
-
-`polaris-reconcile-<slug>-<YYYY-MM-DD>-<seq>` — e.g. `polaris-reconcile-POL-257-2026-06-04-001`
-
-## Telemetry
-
-Append-only JSONL. Required fields: `event`, `run_id`, `timestamp`.
-
-| Event | Trigger |
-|---|---|
-| `run-start` | Begin orient step |
-| `step-complete` | End of every step |
-| `polaris-md-updated` | POLARIS.md written for a folder |
-| `summary-md-updated` | SUMMARY.md written for a folder |
-| `reconcile-commit` | Commit created |
-| `reconcile-complete` | All steps done |
-
-## Artifact authority
-
-`.taskchain_artifacts/polaris-reconcile/current-state.json` is the sole authoritative
-live state surface.
-
-- Update after every completed step — before advancing.
-- A step is NOT complete until the state update succeeds.
-- If the update fails: stop and report the persistence failure.
-
-## Forbidden actions
-
-- src file mutations
-- runtime state file mutations
-- document ingestion or promotion
-- polaris loop continue
-- polaris finalize
-- git push
-- PR creation

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

@@ -1,82 +0,0 @@
----
-name: polaris-reconcile-step-01
-description: Generate run_id, emit run-start telemetry, load packet, validate schema, and establish work_inventory.
----
-
-# Step 01 — Orient reconcile
-
-## Purpose
-
-Establish bounded execution context before touching any files. Validate the packet,
-confirm which folders are in scope, and build the work inventory.
-
-## Actions
-
-### 1.1 Generate run_id
-
-Format: `polaris-reconcile-<issue-slug>-<YYYY-MM-DD>-<seq>`
-Example: `polaris-reconcile-POL-257-2026-06-04-001`
-
-### 1.2 Emit run-start telemetry
-
-First I/O action, before any file access:
-
-```bash
-mkdir -p .taskchain_artifacts/polaris-reconcile/runs/<run-id>
-echo '{"event":"run-start","run_id":"<run-id>","issue_id":"<issue_id>","timestamp":"<ISO>"}' \
-  >> .taskchain_artifacts/polaris-reconcile/runs/<run-id>/telemetry.jsonl
-```
-
-If this write fails: halt. Do not continue.
-
-### 1.3 Validate packet
-
-Confirm the packet contains all required fields:
-`run_id`, `issue_id`, `affected_folders`, `work_inventory`, `allowed_write_paths`,
-`prohibited_write_paths`, `constraints`
-
-If any required field is missing: halt and report which field is absent.
-
-### 1.4 Build work inventory snapshot
-
-From `packet.work_inventory`, confirm:
-- `affected_folders` — list of folder paths whose cognition may need updating
-- `all_changed_files` — files changed by the completed work
-- `child_summaries` — summaries of completed children (if cluster-based)
-- `pending_cognition_notes` — any pending cognition notes per folder
-- `polaris_md_files` — current POLARIS.md paths per folder
-- `summary_md_files` — current SUMMARY.md paths per folder
-
-If `affected_folders` is empty: record as no-op, skip to step 04.
-
-### 1.5 Restate working context
-
-Summarize in under 8 bullets:
-- `run_id` and fresh/resumed
-- Bound issue
-- Affected folders (count and paths)
-- `allowed_write_paths` count
-- `prohibited_write_paths` count
-
-## Scope declarations
-
-```yaml
-allowed_files:
-  - .polaris/skills/polaris-reconcile/SKILL.md
-  - .polaris/skills/polaris-reconcile/chain.md
-  - .taskchain_artifacts/polaris-reconcile/current-state.json
-  - packet (read only)
-stop_rules:
-  - run-start telemetry write fails
-  - packet missing required fields
-```
-
-## Artifact update
-
-Update `.taskchain_artifacts/polaris-reconcile/current-state.json`:
-- `run_id`, `issue_id`, `status: orienting`, `current_step_id: 01-orient-reconcile`
-- `affected_folders`, `updated_at: <timestamp>`
-
-## Next step
-
-02-reconcile-polaris-md

package/dist/workspace/workspace/.polaris/skills/polaris-reconcile/steps/02-reconcile-polaris-md.md

@@ -1,95 +0,0 @@
----
-name: polaris-reconcile-step-02
-description: Update affected POLARIS.md files to accurately reflect the current state of each folder after the completed work.
----
-
-# Step 02 — Reconcile POLARIS.md
-
-## Purpose
-
-Each affected folder's POLARIS.md must accurately describe the current reality of that folder.
-This step performs actual reconciliation — not append-only notes.
-
-## What POLARIS.md Represents
-
-A folder's POLARIS.md is a living operational guide. It should describe:
-- Current capabilities (what this folder does now)
-- Current architecture (how it is structured now)
-- Current responsibilities (what owns what)
-- Current constraints (what is forbidden)
-- Current folder state (what is present and what is not)
-
-POLARIS.md is NOT a changelog. Do not append "added in POL-123". Replace stale
-statements with current truth.
-
-## When to Update
-
-Update a folder's POLARIS.md when ALL of the following are true:
-1. Files in that folder were changed by the completed work.
-2. The changes materially affect the folder's responsibilities, architecture, or constraints.
-3. The current POLARIS.md content is factually wrong or incomplete as a result.
-
-Do NOT update for: formatting fixes, test additions without behavior change,
-internal refactors that leave operational guidance still accurate.
-
-## When NOT to Update
-
-- The folder was not touched by the completed work.
-- The changes are in sub-packages that have their own POLARIS.md.
-- The existing POLARIS.md correctly describes the outcome of the changes.
-
-## Actions
-
-For each folder in `work_inventory.affected_folders`:
-
-### 2.1 Assess the Impact
-
-1. Identify which files in this folder were changed (from `work_inventory.all_changed_files`).
-2. Read the current POLARIS.md content for this folder (from `work_inventory.polaris_md_files`).
-3. Read cognition notes for this folder (from `work_inventory.pending_cognition_notes`).
-4. Cross-reference with child summaries and work summary to understand what changed.
-
-### 2.2 Determine Required Changes
-
-For each stale or missing statement in POLARIS.md:
-- If a capability was added: add it to the appropriate section.
-- If a capability was changed: update the statement in place.
-- If a capability was removed: remove the statement.
-- If a constraint was added: add to constraints section.
-- If a constraint was lifted: remove it.
-- If architecture changed: update the architecture description.
-
-**Reconciliation principle:** The resulting POLARIS.md must describe the folder as it
-exists AFTER the work completed. Read the code if necessary to confirm the current state.
-
-### 2.3 Confidence Threshold
-
-Assess confidence (0.0–1.0) in the proposed update:
-- `≥ 0.85`: Apply the update.
-- `0.70–0.84`: Apply with a note in the result that confidence was moderate.
-- `< 0.70`: Skip the update for this folder, record as a blocker in the result.
-
-Low confidence triggers: ambiguous changed_files, contradictory notes, minimal diff context.
-
-### 2.4 Write
-
-If the assessment confirms an update is needed and confidence is sufficient:
-1. Verify the POLARIS.md path is in `packet.allowed_write_paths`.
-2. Write the full updated content (not a patch — full file replacement).
-3. Record in the running `polaris_md_updates` list.
-
-If the path is in `packet.prohibited_write_paths`, record as a blocker and skip.
-
-## Output
-
-Running list for step 04:
-```yaml
-polaris_md_updates: [
-  { file: "<path>", action: "update", change_summary: "<≤50 words>" },
-  ...
-]
-```
-
-## Next step
-
-03-reconcile-summary-md

package/dist/workspace/workspace/.polaris/skills/polaris-reconcile/steps/03-reconcile-summary-md.md

@@ -1,108 +0,0 @@
----
-name: polaris-reconcile-step-03
-description: Refresh SUMMARY.md files to reflect current project state after the completed work.
----
-
-# Step 03 — Reconcile SUMMARY.md
-
-## Purpose
-
-SUMMARY.md files serve as continuation artifacts, project snapshots, and handoff documents.
-A future session loading SUMMARY.md must be able to continue work immediately without
-replaying history.
-
-The goal is that SUMMARY.md reflects the current state of the project AFTER the completed
-work, not a log of what happened.
-
-## What SUMMARY.md Represents
-
-- Current understanding of the system (what is true now)
-- Canonical references to active specs and doctrine
-- Architecture snapshots that are no longer in flux
-- Handoff context for continuation sessions
-
-SUMMARY.md is NOT:
-- A changelog
-- A history of execution events
-- A list of completed issues
-
-## When to Update
-
-Update a folder's SUMMARY.md when:
-- Linked specs or doctrine changed significantly
-- Canon relationships changed (new spec supersedes old; architecture changed)
-- Architecture meaning changed in ways not captured by POLARIS.md
-- Current understanding described in SUMMARY.md is now stale or contradicted by completed work
-
-Do NOT update for: ephemeral execution events, minor bug fixes, test additions without
-behavior change, changes that do not affect the reader's understanding.
-
-## Reconciliation Principles
-
-### Remove Stale Information
-
-Identify statements that are contradicted by the completed work. Remove or replace them.
-Do not preserve stale content by appending "as of POL-XXX".
-
-### Replace Superseded Information
-
-When a spec or decision that SUMMARY.md references has been superseded, update the reference
-to point to the current authority.
-
-### Preserve Current Understanding
-
-Retain content that accurately describes current reality. Preservation is not append — it is
-selection of what remains true.
-
-### Root-level SUMMARY.md
-
-The root-level SUMMARY.md (if in `packet.affected_folders`) must reflect the overall project
-state after the completed work. Give it higher priority than folder-level SUMMARY.md files.
-
-## Actions
-
-For each folder in `work_inventory.affected_folders` that has a SUMMARY.md:
-
-### 3.1 Assess Staleness
-
-1. Read the current SUMMARY.md (from `work_inventory.summary_md_files`).
-2. Cross-reference with completed work: changed specs, new capabilities, new constraints.
-3. Identify sections that are stale, contradicted, or superseded.
-4. Identify new information that should be captured.
-
-### 3.2 Refresh
-
-Produce the updated SUMMARY.md content:
-1. Remove sections that are no longer accurate.
-2. Update references to specs and doctrine that changed.
-3. Add brief architecture notes for significant new capabilities (if they help future sessions).
-4. Ensure the document still reads as a coherent current-state snapshot, not a list of events.
-
-**Constraint:** SUMMARY.md updates must not exceed `packet.constraints.max_summary_addition_lines`
-net new lines per folder (default: 50 lines). Replacements (same or fewer lines) do not
-count toward this limit.
-
-### 3.3 Write
-
-1. Verify the SUMMARY.md path is in `packet.allowed_write_paths`.
-   If not allowed, skip this file and record with `action: "path_not_allowed"`.
-2. Write the full updated content.
-3. Record in the running `summary_md_updates` list.
-
-If no update is needed, record no-change with `action: "no_change"`.
-
-## Output
-
-Running list for step 04:
-```yaml
-summary_md_updates: [
-  { file: "<path>", action: "update", change_summary: "<≤50 words>" },
-  { file: "<path>", action: "no_change" },
-  { file: "<path>", action: "path_not_allowed" },
-  ...
-]
-```
-
-## Next step
-
-04-reconcile-commit

package/dist/workspace/workspace/.polaris/skills/polaris-reconcile/steps/04-reconcile-commit.md

@@ -1,88 +0,0 @@
----
-name: polaris-reconcile-step-04
-description: Commit all cognition changes (POLARIS.md and SUMMARY.md updates) as a single sealed reconcile commit.
----
-
-# Step 04 — Reconcile commit
-
-## Purpose
-
-All cognition changes produced by steps 02–03 must be committed as a single sealed commit.
-This separates implementation commits from documentation reconciliation commits.
-
-## Commit constraints
-
-The reconcile commit MUST:
-- Contain only files from `packet.allowed_write_paths`
-- Contain only POLARIS.md and SUMMARY.md changes — no implementation source, no runtime state
-- Be a distinct commit from any implementation commit
-
-If any staged file would violate these constraints, unstage it and record as a blocker.
-
-## No-change case
-
-If steps 02–03 produced no file changes (everything was already current), this step is a
-no-op. Record `commit_sha: null`. Do not create an empty commit.
-
-## Commit message format
-
-```text
-docs(reconcile): update cognition for <issue_id>
-
-Run: <run_id>
-Issue: <issue_id>
-Files updated:
-- POLARIS.md: <count> files
-- SUMMARY.md: <count> files
-```
-
-## Actions
-
-### 4.1 Pre-commit validation
-
-Verify:
-1. Every file to be committed is in `packet.allowed_write_paths`.
-2. No file is in `packet.prohibited_write_paths`.
-3. At least one non-empty change exists.
-
-If prohibited files are staged: `git reset HEAD <file>` before committing.
-
-### 4.2 Stage changed files
-
-```bash
-git add <polaris_md_updates[*].file where action == "update">
-git add <summary_md_updates[*].file where action == "update">
-```
-
-### 4.3 Verify staged files
-
-Run `git diff --cached --name-only` and confirm all staged files are in
-`packet.allowed_write_paths` and none are in `packet.prohibited_write_paths`.
-
-### 4.4 Commit
-
-```bash
-git commit -m "<commit message>"
-```
-
-Capture the resulting commit SHA.
-
-### 4.5 Finalize
-
-Update `.taskchain_artifacts/polaris-reconcile/current-state.json`:
-- `status: complete`
-- `current_step_id: 04-reconcile-commit`
-- `commit_sha: <sha or null>`
-- `completed_at: <ISO timestamp>`
-
-Emit `reconcile-commit` and `reconcile-complete` telemetry events.
-
-Report summary:
-```text
-polaris-reconcile complete
-Issue:      <issue_id>
-POLARIS.md: <count> files updated
-SUMMARY.md: <count> files updated
-Commit:     <sha> | no changes
-Blockers:   <none | list>
-```

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

@@ -1,135 +0,0 @@
----
-name: polaris-run
-description: Execute one governed Polaris parent cluster per session, dispatching children until all are done or the configured budget is exhausted (budget.mode and budget.max_children in polaris.config.json), with explicit dispatch boundaries and post-child checkpointing.
-role: foreman
-role_file: .polaris/roles/foreman.md
----
-
-## Command entrypoints
-
-This skill is the target for the following user commands:
-
-- `polaris-run <POL-###>`
-- `run polaris-run on issue <POL-###>`
-- `run polaris-run on <POL-###>`
-- `polaris-finalize`
-- `run polaris-finalize`
-
-When any of these commands are issued, load this skill packet **first** before any other action.
-If the command specifies an issue ID (e.g., `POL-249`), bind exactly that issue. Commands without
-an issue ID (e.g., `polaris-finalize`) do not require issue binding. `polaris-finalize` routes
-here because finalization is part of the run lifecycle governed by this skill. See
-`.polaris/skills/ROUTING.md` for the full routing protocol.
-
----
-
-## Polaris Skill Bootloader
-
-**Before proceeding, you must obtain a skill packet from the Polaris runtime.**
-
-Run the following command:
-
-```
-npm run polaris -- skill packet run
-```
-
-- Do not begin work until a packet is returned.
-- Treat the packet as your authoritative instruction source.
-- The packet defines your active role, authority boundaries, prohibited actions, deliverables, and stop conditions.
-- If no packet is produced, stop and report: **Polaris could not authorize this run.**
-
----
-
-# polaris-run
-
-Use this skill when the user asks to run a governed Polaris implementation cluster or standalone Polaris issue.
-
-polaris-run only targets IMPLEMENT parents. If Step 01 detects a parent title
-starting with `ANALYZE:` or an `analyze` label, halt with:
-`polaris-run targets IMPLEMENT parents, not ANALYZE issues. Run polaris-analyze first to create an IMPLEMENT parent.`
-
-## Related doctrine
-
-See `docs/Polaris/spec/polaris-implementation-plan.md` for the Polaris architecture reference.
-
-## How to execute
-
-1. Read `chain.md` — it is the route map for this workflow.
-2. Read `.taskchain_artifacts/polaris-run/current-state.json` — it holds shared runtime state across sessions.
-3. Execute one step at a time in the order `chain.md` specifies.
-4. After each durable checkpoint, update `.taskchain_artifacts/polaris-run/current-state.json` before advancing.
-5. Do not skip steps.
-6. Do not report completion until `.taskchain_artifacts/polaris-run/current-state.json` has `status: complete`.
-
-## Artifact authority rule
-
-`.taskchain_artifacts/polaris-run/current-state.json` is the authoritative run ledger, not an optional note.
-
-A step is not complete until its state update has been written successfully.
-
-If the artifact update fails or cannot be verified, stop and report the artifact failure instead of continuing.
-
-## Hard rules
-
-- Implementation work only — source code, tests, config changes.
-- One child per commit. Never batch multiple children into one commit.
-- Do not implement child work inline in the parent. Use `polaris loop dispatch` to dispatch a worker.
-- `polaris loop continue` is post-child only. Do not call it before the worker has returned.
-- Do not call `polaris loop continue` without a preceding commit.
-- `polaris finalize` replaces manual push and PR — do not push or open PRs directly.
-
-## Runtime-enforced dispatch boundaries
-
-**The runtime enforces dispatch boundaries. Parent/orchestrator inline implementation is forbidden.**
-
-The Polaris runtime tracks a `dispatch_boundary` record in `current-state.json` with monotonic epoch counters:
-
-```json
-{
-  "dispatch_boundary": {
-    "dispatch_epoch": 1,
-    "continue_epoch": 0,
-    "last_dispatched_child": "POL-23"
-  }
-}
-```
-
-### Enforcement rules
-
-- `polaris loop continue` **will hard-fail** if `dispatch_epoch === continue_epoch` (no dispatch preceded this call).
-- `polaris loop dispatch` **will hard-fail** if `active_child` is already set (previous dispatch not completed).
-- `polaris loop run` (parent loop) **will hard-fail** if `active_child` is set at the start of a dispatch iteration.
-
-These are not warnings. They are runtime errors with `process.exit(1)`.
-
-### Allowed state machine transitions
-
-```
-idle           → dispatched        (polaris loop dispatch)
-checkpointed   → dispatched        (polaris loop dispatch, next child)
-dispatched     → worker-completed  (worker CompactReturn)
-worker-completed → checkpointed    (polaris loop continue)
-dispatched     → checkpointed      (polaris loop continue when worker wrote own completion)
-checkpointed   → cluster-complete  (polaris loop continue, no remaining children)
-*              → blocked           (polaris loop abort)
-```
-
-### Disallowed transitions (runtime-rejected)
-
-```
-idle           → worker-completed  (worker completed without dispatch)
-idle           → checkpointed      (continue called without dispatch)
-idle           → cluster-complete  (cluster done without dispatch path)
-selected       → completed         (inline completion — forbidden)
-selected       → checkpointed      (checkpoint without dispatch — forbidden)
-```
-
-### Telemetry events emitted on violation
-
-| Event | When |
-|---|---|
-| `dispatch-required` | `polaris loop continue` called without prior dispatch |
-| `invalid-inline-attempt` | `polaris loop dispatch` called with `active_child` already set |
-| `illegal-state-transition` | Parent tries to complete child without dispatch boundary |
-
-These events are append-only to `telemetry.jsonl` and appear only on failure paths.

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

@@ -1,19 +0,0 @@
-{
-  "name": "polaris-run-chain",
-  "steps": [
-    "01-orient-cluster",
-    "02-prepare-branch",
-    "03-select-child",
-    "04-execute-child",
-    "05-validate-child",
-    "06-commit-and-update-linear",
-    "07-decide-continuation",
-    "08-final-delivery"
-  ],
-  "loop_re_entry": "03-select-child",
-  "terminal_steps": ["08-final-delivery"],
-  "polaris_calls": {
-    "07-decide-continuation": ["polaris loop dispatch", "polaris loop continue"],
-    "08-final-delivery": ["polaris finalize"]
-  }
-}