@dotobokuri/fleet-cli 1.5.3 → 1.5.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dotobokuri/fleet-cli",
-  "version": "1.5.3",
+  "version": "1.5.5",
   "description": "Fleet CLI — a multi-LLM orchestration kit that operates Claude Code and Codex CLI through a single unified interface.",
   "repository": {
     "type": "git",
@@ -18,7 +18,6 @@
   },
   "files": [
     "dist",
-    "assets",
     "bin",
     "postinstall.mjs",
     "README.md"
@@ -27,7 +26,7 @@
     "postinstall": "node postinstall.mjs"
   },
   "dependencies": {
-    "@dotobokuri/fleet-console": "1.5.3",
+    "@dotobokuri/fleet-console": "1.5.5",
     "@clack/prompts": "1.4.0",
     "@xterm/headless": "^5.5.0",
     "node-pty": "^1.0.0"

package/assets/skills/assumption-audit/SKILL.md

@@ -1,16 +0,0 @@
----
-name: assumption-audit
-description: Resolve decision-shaped Context Confidence gate failures one blocking gap at a time before the active protocol re-applies its planning boundary.
----
-
-Use this auxiliary skill only when the active protocol or Context Confidence re-entry path has already found an unresolved blocking gap and the gap is decision-shaped. This skill is not a protocol mode, does not replace the active protocol, and cannot declare the planning boundary passed by itself.
-
-For each unresolved blocking gap, triage the gap before questioning:
-
-- **Scout-shaped**: the answer should come from direct file reads, focused reconnaissance, carrier scouting, or another verifiable evidence source. Send the workflow back to that evidence-gathering path instead of asking the user to decide.
-- **Decision-shaped**: the answer depends on preference, scope, risk appetite, product intent, or authority that evidence alone cannot settle. Ask exactly one question for this gap.
-- **Escalation-shaped**: the answer requires authority beyond the current operator, changes the mission boundary, repeatedly fails to resolve, or would weaken the active protocol's required gate. Escalate to the Admiral of the Navy (대원수).
-
-When a gap is decision-shaped, ask one question at a time. Present your recommended answer first, then give one or two concrete alternatives when useful. Walk decision dependencies one branch at a time until the current gap is resolved; do not bundle unrelated gaps into the same question.
-
-After the gap is answered, report the resolved decision in one short line and return control to the active protocol or Context Confidence Standing Order. The active workflow must re-evaluate confidence and re-apply the required planning boundary gate before planning proceeds.

package/assets/skills/protocol-baseline/SKILL.md

@@ -1,37 +0,0 @@
----
-name: protocol-baseline
-description: Use the compact Fleet protocol mode for simple, reversible, single-surface work.
----
-
-# Fleet Protocol: Baseline
-
-Use this mode only for simple, reversible, single-surface operational work.
-
-At any point during the work, if a Downward Guard trigger appears, stop and re-classify.
-
-## Checkpoints
-
-None. Selecting baseline implies Mission Anchor Compact Mode.
-
-## Reporting Cadence
-
-As you move through this protocol, report progress to the Admiral of the Navy in order.
-
-1. Brief in one line how the Workflow will proceed. → report `brief: <…>`
-2. State that execution is beginning and run the Workflow. → report `status: executing`
-
-## General Quarters
-
-Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to the Objective anchor. These checks prepare the work; they do not gate entry.
-
-- [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
-- [ ] **Single surface** — the exact file, command, or fact is identified. → report `surface: <x>`
-- [ ] **Reversibility** — the change is trivially reversible. → report `reversible: yes`
-
-## Workflow
-
-1. Objective statement: state the Mission Anchor objective in one line.
-2. Exact fact/file verification: verify the exact file, command, or fact needed for the request.
-3. Execution: make the smallest reversible change or run the exact requested command.
-4. Result verification: check the touched surface or command result.
-5. One-line report: report what changed, verification, and any skipped escalation trigger.

package/assets/skills/protocol-frontline/SKILL.md

@@ -1,42 +0,0 @@
----
-name: protocol-frontline
-description: Use the coordinated Fleet protocol mode for multi-carrier or parallel ownership work.
----
-
-# Fleet Protocol: Frontline
-
-Use this mode when operational work requires multiple Carriers, independent parallel workstreams, cross-carrier review loops, or file ownership coordination. If the work is high risk but single-owner, use `protocol-redline` instead.
-
-## Checkpoints
-
-Decomposition, Dispatch, Integration, Verification.
-
-## Reporting Cadence
-
-As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token.
-
-1. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) each carrier's file or responsibility ownership, and (c) the dispatch wave sequencing. → report `brief: <…>`
-2. State that execution is beginning and run the Workflow. → report `status: executing`
-
-## General Quarters
-
-Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to reconnaissance and decomposition. These checks prepare the work; they do not gate entry.
-
-- [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
-- [ ] **Impact radius** — flag public-surface or API impact, irreversibility, and any security-sensitive surface. → report `impact: <…>`
-- [ ] **Rollback** — identify a rollback-safe checkpoint and any Admiral of the Navy approval point before execution begins. → report `rollback: <…>`
-- [ ] **Carrier availability** — confirm the intended carriers are actually exposed and available this session. → report `carriers: <…>`
-- [ ] **Ownership** — pre-sketch each carrier's file or responsibility boundary. → report `ownership: <…>`
-- [ ] **Shared resources** — flag shared mutable resources (same files, lock files, or a singleton test environment). → report `shared: <…|none>`
-- [ ] **Dependencies** — pre-classify parallel versus sequential work before decomposition and dispatch. → report `dependencies: <parallel|sequenced: …>`
-
-## Workflow
-
-1. Reconnaissance and decomposition: audit known facts, identify gaps, map affected surfaces, and split work into independently verifiable missions.
-2. Ownership graph: assign each Carrier a clear file or responsibility boundary, note dependencies, and identify shared mutable resources.
-3. Structured planning boundary: `Apply the Context Confidence Standing Order — entry requires complete`. Resolve all blocking and confirmatory gaps before dispatch planning.
-4. Parallel dispatch: use Carrier Operations Policy to launch independent Carrier work in parallel; sequence only for explicit dependencies or shared resources.
-5. Integration: re-read files before editing or accepting Carrier output, reconcile overlaps, and preserve unrelated user or Carrier changes.
-6. Cross-carrier review loop: route implementation outputs to review Carriers, send actionable findings back to owners, and re-review changed surfaces.
-7. Verification: run integrated tests and apply Deep Dive to speculative or conflicting Carrier claims.
-8. Documentation and completion report: update directly affected docs and report executed waves, Carrier ownership, QA, unresolved risks, and final Result Integrity checks.

package/assets/skills/protocol-midline/SKILL.md

@@ -1,39 +0,0 @@
----
-name: protocol-midline
-description: Use the normal Fleet protocol mode for bounded operational work without downward-guard triggers.
----
-
-# Fleet Protocol: Midline
-
-Use this mode for ordinary bounded operational work.
-
-At any point during the work, if a Downward Guard trigger appears, stop and re-classify.
-
-## Checkpoints
-
-Reconnaissance, Plan, Execution, Verification.
-
-## Reporting Cadence
-
-As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token.
-
-1. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) the target surfaces, and (c) the verification command. → report `brief: <…>`
-2. State that execution is beginning and run the Workflow. → report `status: executing`
-
-## General Quarters
-
-Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to focused reconnaissance. These checks prepare the work; they do not gate entry.
-
-- [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
-- [ ] **Target surfaces** — provisionally name the minimal modules or files reconnaissance will touch; confirm or revise in the brief after reconnaissance. → report `surfaces: <…>`
-- [ ] **Verification** — provisionally pre-load the test, build, or check command that will prove the work done; confirm or revise in the brief after reconnaissance. → report `verify: <cmd>`
-- [ ] **Carrier** — declare whether a carrier sortie is needed. → report `carrier: <none|…>`
-
-## Workflow
-
-1. Focused reconnaissance: audit known facts, identify blocking and confirmatory gaps, and inspect the minimal relevant surfaces.
-2. Planning boundary: `Apply the Context Confidence Standing Order — entry requires sufficient`. Resolve all blocking gaps before planning.
-3. Inline plan: state objective, targets, execution steps, and done criteria.
-4. Execution: implement the plan in narrow batches, using Carrier Operations Policy when delegation is appropriate.
-5. Verification and review: run targeted checks, apply Deep Dive to speculative results, and fix actionable issues.
-6. Documentation and final report: update directly affected docs only when behavior or operator guidance changed, then summarize changes and QA.

package/assets/skills/protocol-redline/SKILL.md

@@ -1,40 +0,0 @@
----
-name: protocol-redline
-description: Use the risk-controlled Fleet protocol mode for irreversible, structural, multi-module, or prompt-policy work.
----
-
-# Fleet Protocol: Redline
-
-Use this mode for irreversible operations, structural/API changes, cross-module edits, doctrine or prompt-policy edits, security-sensitive work, or any operational request needing explicit risk controls. Escalate to `protocol-frontline` when multiple Carriers or parallel ownership boundaries are required.
-
-## Checkpoints
-
-Reconnaissance, Risk review, Plan, Execution, Verification.
-
-## Reporting Cadence
-
-As you move through this protocol, report progress to the Admiral of the Navy in order — each step on its own line with its report token.
-
-1. Brief how the Workflow will proceed — name (a) the Workflow steps that will run, (b) file ownership and the rollback-safe checkpoint, and (c) the risk controls in force. → report `brief: <…>`
-2. State that execution is beginning and run the Workflow. → report `status: executing`
-
-## General Quarters
-
-Confirm each readiness check below before the Workflow. Work through them in order and report each as you confirm it, then proceed to full reconnaissance. These checks prepare the work; they do not gate entry.
-
-- [ ] **Common** — objective stated (Mission Anchor), mode-fit holds (Mode Gate), Standing Orders binding. → report `common: ready`
-- [ ] **Doctrine** — enumerate the applicable AGENTS.md files to load for the affected scope. → report `doctrine: <…>`
-- [ ] **Impact radius** — flag public-surface or API impact, irreversibility, and any security-sensitive surface. → report `impact: <…>`
-- [ ] **Rollback** — identify a rollback-safe checkpoint and any Admiral of the Navy approval point before execution begins. → report `rollback: <…>`
-- [ ] **Escalation** — if multiple carriers or parallel ownership boundaries are required, re-classify under frontline. → report `escalation: clear`
-
-## Workflow
-
-1. Full reconnaissance: audit known facts, enumerate blocking and confirmatory gaps, read applicable AGENTS.md files, map affected code, tests, docs, and boundaries.
-2. Architecture and risk review: identify public-surface impact, dependency constraints, rollback risk, security risk, and Admiral of the Navy approval requirements.
-3. Structured planning boundary: `Apply the Context Confidence Standing Order — entry requires complete`. Do not plan with unresolved blocking or confirmatory gaps.
-4. Risk-controlled plan: define file ownership, small execution batches, verification commands, rollback-safe checkpoints, and any approval point.
-5. Small-batch execution: edit narrowly, re-read before modifying shared files, and pause on unexpected diffs or scope expansion.
-6. Refactor gate: refactor only touched code when duplication, complexity, or convention drift appears, only with Admiral of the Navy approval or when pre-declared in the brief.
-7. Correctness and security review (may run as a single combined review dispatch): review changed behavior and risk controls; apply Deep Dive to speculative findings and repeat after fixes.
-8. Documentation and completion report: update directly affected operator docs and report changes, QA, risk controls, and residual uncertainty.