From 8fb515d2bb892cf2ec4c144793ac9e1cbfc7a38d Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Thu, 1 Oct 2026 15:37:00 -0400 Subject: [PATCH] TASK-conversation-documentation-current: refresh README pilot status --- README.md | 54 +++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index ae8641f..fc49eac 100644 --- a/README.md +++ b/README.md @@ -6,14 +6,26 @@ domain-specialized AI development sessions. The new TORCH is being extracted from the agent-fleet operating model proven in COMBATRIG. It is local-first, provider-independent, worktree-isolated, and designed to manage its own development. The former Nostr lock/scheduler product -is preserved on the `legacy/nostr-torch` branch and is not part of this -architecture. +is preserved on the [`legacy/nostr-torch` branch](https://github.com/PR0M3TH3AN/TORCH/tree/legacy/nostr-torch) +and is not part of this architecture. ## Current status -The rewrite is under active development on `rewrite/portable-agent-fleet`. -The current implementation provides the portable kernel, project bootstrap, -and the first Claude reference-fleet path: +The rewrite is under active development on the +[`rewrite/portable-agent-fleet` branch](https://github.com/PR0M3TH3AN/TORCH/tree/rewrite/portable-agent-fleet). +The repository declares version `0.1.0-alpha.3`. This remains experimental: +the current owner-managed TORCH-on-TORCH development pilot is Codex-run, and +does not qualify production use or a live switch among providers. + +The active pilot uses a previously accepted, immutable `0.1.0-alpha.3` +installation artifact. Its installed source snapshot is separate from this +development branch: later source commits do not become installed features +automatically. Existing processes may also keep code loaded from the version +they started with; changing the active installation pointer does not hot-reload +them. + +The current source provides portable-kernel, project-bootstrap, and local +coordination foundations: - read-only Git repository inspection; - repository inventory and check discovery; @@ -45,8 +57,8 @@ and the first Claude reference-fleet path: - live ownership, neighbours, handoff, coordination, completion, and blocker operations; - equivalent CLI and identity-bound MCP surfaces; - current MCP stdio interoperability through the official protocol SDK; -- explicit-capability Claude, Codex, and Pi adapters with per-identity - model/reasoning selection; +- built-in Claude, Codex, and Pi adapters with explicit capabilities and + per-identity model/reasoning selection; - identity-bound MCP registration for Claude/Codex and a bundled Pi extension that exposes the same TORCH tool set through Pi's extension API; - invocation-scoped runtime configuration without changing the user's global @@ -86,7 +98,7 @@ and the first Claude reference-fleet path: - validated system/session schedules with shell-free actions, authority, retries, durable run evidence, and explicit approval for mutation; - an owner-approved user-systemd launcher for system schedules, bound to the - exact tracked configuration digest and recorded for exact reversal. + exact tracked configuration digest and recorded for exact reversal; - durable Fleet evolution: the Session Manager can propose a justified new persistent domain after a read-only assessment of recurring backlog, handoff, and coordination signals, while owner approval gates the configuration commit, @@ -97,14 +109,26 @@ and the first Claude reference-fleet path: deliberately cannot rewrite ownership: TORCH reports the separate migration proof still required for backlog, branches, prompts, worktrees, and neighbours. -Live mixed-provider qualification, stable self-host bootstrapping, COMBATRIG -cutover, installation of the implemented system-schedule launcher on this -machine, and public deployment remain staged work. +These capabilities have different evidence levels. Local scenarios and isolated +fixtures cover many CLI, adapter, Pi-extension, and candidate workflows; they do +not establish live mixed-provider operation, production readiness, or the +security of every candidate-engine boundary. The current Codex pilot is real +TORCH-on-TORCH development evidence, not proof that Claude and Pi were switched +live in the same workflow. + +For this machine's pilot, the owner-approved per-user system-schedule timer is +installed and running. This is distinct from defining a schedule or reviewing +the generic launcher commands below. Automatic AI wakes remain paused. General +first-install/init automation is not yet qualified. Deeper candidate engine, +execution-fence, and private-admission assurance; pipeline execution and +dashboard/served-provenance work; live UX review; stable self-host bootstrapping; +COMBATRIG cutover; live mixed-provider qualification; and release/deployment +qualification remain open. The canonical architecture and delivery plan is -[docs/PORTABLE_AGENT_FLEET_SPEC.md](docs/PORTABLE_AGENT_FLEET_SPEC.md). +[docs/PORTABLE_AGENT_FLEET_SPEC.md](https://github.com/PR0M3TH3AN/TORCH/blob/rewrite/portable-agent-fleet/docs/PORTABLE_AGENT_FLEET_SPEC.md). Resolved implementation choices and deliberately gated boundaries are recorded -in [docs/ARCHITECTURE_DECISIONS.md](docs/ARCHITECTURE_DECISIONS.md). +in [docs/ARCHITECTURE_DECISIONS.md](https://github.com/PR0M3TH3AN/TORCH/blob/rewrite/portable-agent-fleet/docs/ARCHITECTURE_DECISIONS.md). ## Development @@ -565,8 +589,8 @@ through the atomic active-version link; it refuses an unrelated existing path. ```bash node bin/torch.mjs candidate plan --source . --json node bin/torch.mjs candidate build --source . --yes --json -node bin/torch.mjs upgrade --version 0.1.0-alpha.0 --dry-run --json -node bin/torch.mjs upgrade --version 0.1.0-alpha.0 --yes --json +node bin/torch.mjs upgrade --version 0.1.0-alpha.3 --dry-run --json +node bin/torch.mjs upgrade --version 0.1.0-alpha.3 --yes --json node bin/torch.mjs rollback --dry-run --json ```