Releases: mahadansar/sol-luna-orchestrator
Release list
v0.12.0
v0.12.0
This release focuses on making adaptive routing more practical, observable, and reliable in real execution.
Highlights
- Improved adaptive routing so Sol can identify bounded delegation opportunities without becoming overly aggressive.
- Added safer support for single/sequential delegation when work is coupled but still separable.
- Kept unsafe parallelism blocked for mutable/shared-state workloads.
- Added routing rule/provenance telemetry for easier diagnosis.
- Hardened capability redaction across diagnostics, events, usage metadata, and legacy event paths.
- Fixed cancellation-state integrity across recovery, evidence scanning, semaphore waits, and activity projections.
- Improved Benchmark V3 campaign analysis and reproducibility metadata handling.
- Made benchmark history tests hermetic across clean CI environments.
- Updated documentation with the completed Benchmark V3 results.
Benchmark V3
Benchmark V3 completed 36/36 valid runs against the v0.11.0 baseline.
The campaign showed that v0.11.0 Adaptive Medium remained Solo across all tested workloads, adding orchestration overhead without using workers. Those findings directly informed the routing changes in v0.12.0.
The benchmark uses two repetitions and should be treated as directional evidence, not a statistically significant performance claim. v0.12.0 itself has not yet been compared against v0.11.0 in a new full benchmark campaign.
Validation
- 1,074 tests passing
- 0 failures
- 3 expected platform-specific skips
- Protocol smoke: PASS
- Benchmark fixture validation: PASS
npm audit: 0 vulnerabilities- Global packaged MCP smoke: PASS
- Real
gpt-5.6-lunadelegation verified through the packaged global MCP
v0.11.0
What's new in v0.11.0
v0.11.0 expands the Thin Supervisor foundation from v0.10.0 with adaptive routing, stronger execution controls, context lifecycle management, resumable workflows, and substantial runtime/security hardening.
Adaptive routing and compute policy
- Added adaptive routing for solo, single-worker, sequential, and parallel execution.
- Added semantic task/seam planning to improve delegation decisions.
- Added operator-controlled model, effort, worker-count, and concurrency limits.
- Added bounded effort escalation and stronger-executor fallback based on authoritative failure evidence.
Failure handling and recovery
- Added structured failure decisions for stop, repair, continuation, retry, escalation, fallback, and parent takeover.
- Added bounded repair and parallel recovery without uncontrolled retry chains.
- Improved attribution across initial attempts, repairs, recoveries, and verification.
Context and handoff lifecycle
- Added automatic context pressure detection and compaction while preserving authoritative evidence and lineage.
- Added single-use next-action handoffs for safely carrying earned execution authority between attempts.
- Added portable cross-session informational handoffs without carrying execution authority across sessions.
- Improved continuation lifecycle, capability expiry, and context reclamation.
Exploration and workflow coordination
- Added an optional read-only Explorer for scoped investigation before delegation.
- Added the bounded end-to-end workflow coordinator for assessment, routing, delegation, verification, recovery, and parent takeover.
Security and runtime hardening
- Hardened Windows executable resolution and command execution.
- Protected .git and .sol-luna control metadata from delegated changes.
- Hardened symlink/junction handling and integration destination checks.
- Hardened Git evidence collection against repository-controlled helpers.
- Added graceful shutdown and stronger cancellation/process-tree handling.
- Improved worktree, capability, context, and cleanup ownership under failures and concurrency.
- Prevented cancelled work from being incorrectly treated as verified or eligible for continuation.
Observability and diagnostics
- Expanded structured lifecycle, routing, context, workflow, integration, and attempt evidence.
- Improved status and doctor reporting for compute-policy and configuration issues.
- Added stronger privacy boundaries around model output, capabilities, and task context.
Validation
v0.11.0 passed the full deterministic release suite with 988 tests passing, 0 failures, and 3 expected platform-specific skips, along with protocol smoke tests, benchmark fixture validation, package validation, and npm audit with 0 vulnerabilities.
Benchmark V3 has not been executed. Its methodology and harness remain frozen for a separate future benchmark campaign.
v0.10.0 - Thin Supervisor
What's Changed
v0.10.0 introduces the Thin Supervisor execution model, reducing unnecessary supervisor-side work around delegated tasks while keeping verification, ownership, and failure handling explicit.
Highlights
- Added deterministic final-workspace verification for delegated batches.
- Added explicit
verified-completeandneeds-supervisorterminal states. - Clean verified PASS responses now use a thin handoff by default.
- Added bounded targeted recovery for eligible worker timeouts/process failures.
- Successful sibling work is preserved when an eligible task requires recovery.
- Reduced repeated MCP instruction, tool-schema, and successful-result overhead.
- Failures and suspicious states still expand into richer diagnostic evidence when needed.
- Improved activity and observability for final verification and recovery.
- Fixed Benchmark V2 analysis so Solo runs no longer receive meaningless Solo-vs-Solo near-tie repetition recommendations.
Migration
This release intentionally changes the default successful-response behavior.
Previously, callers that omitted resultDetail received the full structured successful response.
In v0.10.0, a clean verified PASS defaults to the thin handoff and may omit structuredContent.
If your integration relies on structured successful responses, explicitly request:
resultDetail="compact"- or
resultDetail="full"
Benchmark V2
The Thin Supervisor redesign substantially reduced unnecessary supervisor duplication and zero-worker orchestration overhead in the frozen Benchmark V2 campaign.
However, the final Adaptive configuration did not beat Solo overall on cost, so this release does not claim universal credit or latency savings. The benchmark evidence and limitations remain documented in the repository.
Upgrade
npm install -g sol-luna-orchestrator@0.10.0v0.9.1
Maintenance and hardening release for the v0.9 line.
What's changed
- Fixed post-v0.9.0 runtime issues discovered during hardening.
- Corrected retention configuration precedence behavior.
- Improved runtime robustness and defensive handling.
- Reconciled configuration, security, troubleshooting, observability, roadmap, and release documentation.
- Consolidated validation evidence into "FEATURE_ACCEPTANCE.md" and removed the retired "findings.md" ledger.
- General cleanup and release-readiness improvements.
Validation
- 472/472 tests passing
- Build validation passed
- Smoke validation passed
- Formatting checks passed
- Benchmark validation passed
- Release/package checks passed
This release contains fixes and maintenance only. No new major product capability is introduced.
v0.9.0
v0.9.0
v0.9.0 focuses on tighter task contracts, safer follow-up work, stronger evidence handling, and more reliable batch/worktree execution.
Highlights
-
Explicit Change Intent
Delegated tasks can now declare whether changes arerequired,optional, orforbidden, independently of file scope. -
Worker Continuation
Eligible tasks can resume the same worker thread for one bounded follow-up while preserving the original contract and verification rules. -
Bounded Repair
Tasks can optionally receive one conservative same-thread repair attempt after a qualifying authoritative verification failure. -
Stronger batch and worktree lifecycle
Parallel execution now has improved worktree isolation, lease ownership, cleanup, integration evidence, and failure handling. -
Better verification and reconciliation
Structured worker failure causes are preserved, while authoritative verification can safely resolve the narrow verification-only contradiction case without hiding the original worker claim. -
Parent and cost foundations
Added explicit parent-identity provenance, billing-context separation, caller-supplied rate cards, observed usage accounting, and safe unavailable states without guessing account or pricing information. -
Improved documentation and setup guidance
Documentation was consolidated around clearer sources of truth, the setup/update lifecycle was simplified, and feature acceptance now has a dedicated evidence and confidence ledger.
Reliability
This release also includes additional hardening around:
- sequential and parallel batch evidence
- integration conflict reporting
- retained-worktree continuation
- lease renewal and cleanup
- cancellation lifecycle
- activity and privacy reporting
- live-model structured-output compatibility
For the full list of changes, see the CHANGELOG.
sol-luna-orchestrator v0.8.1
Release notes — v0.8.1
This file stages the reviewed body of the v0.8.1 GitHub Release, dated
2026-08-23. It is not a record of past releases:
- Shipped releases are recorded in
CHANGELOG.md, which is
authoritative. - Published release bodies live on the
Releases page.
Currently in preparation: v0.8.1, dated 2026-08-23.
sol-luna-orchestrator v0.8.1 — 2026-08-23
What changed
- Delegation guidance is adaptive: zero workers remains valid, and cost
decisions balance expected credits, latency, context, fixed overhead,
verification, coordination risk and quality. Cheaper-worker economics apply
only when the selected parent is priced above the worker on the current
schedule; no saving is guaranteed or measured. - Single-task and batch choices are distinct. Use
delegate_taskwhen no
batch-level scheduling is needed;delegate_tasksis intended for multiple
meaningful tasks but accepts one task for compatibility. Sequential batches
are for dependent or shared-workspace tasks, while parallel batches are for
independent tasks. Declared overlap can be accepted per call, but actual
same-file edits still prevent automatic integration. resultDetailin a batch is one batch-level choice applied uniformly to every
returned task result. An emptyallowedFilesarray means no in-workspace
allowlist; it does not declare read-only intent, and workspace confinement
still applies.- The roadmap records a future explicit classification for read-only,
zero-change results and does not infer that intent fromallowedFiles: []. - Human pricing examples are dated 2026-08-23: the documented API example gives
a 25:1 Sol:Luna unit-price ratio, while the eligible purchased-credit example
gives 20:1 for input and cached input and about 16.7:1 for output. These are
illustrative rate ratios, not a measured saving or a universal billing rule. - Regression tests cover adaptive cost guidance, single-versus-batch and overlap
wording, batch-level result detail, empty-allowlist semantics, pricing-example
safeguards and the read-only roadmap distinction.
Unchanged
No delegation input/output schema shape changed, and no execution algorithm
changed. This release updates guidance and schema descriptions while preserving
the established delegation behavior and defaults.
Links
v0.8.0
Release notes — v0.8.0
This file stages the reviewed body of the v0.8.0 GitHub Release, dated
2026-08-22. It is not a record of past releases:
- Shipped releases are recorded in
CHANGELOG.md, which is
authoritative. - Published release bodies live on the
Releases page.
Staging the narrative here rather than in the changelog means the release body
can be reviewed before the tag exists. Once the release has shipped, clear this
file back to an outline: a copy of an entry that is already published only drifts
from it.
Currently in preparation: v0.8.0, dated 2026-08-22. Everything below is the
accepted release body for the unshipped work sitting in main.
sol-luna-orchestrator v0.8.0 — 2026-08-22
What this release is for
Two themes, and they are related.
The first is being found. Deciding well between solo work, one delegated
task, and a batch only matters if the parent gets as far as reading this
project's guidance in the first place, and in fresh sessions it often did not.
The persistent hint init installs used to say "consider" the orchestrator,
which turned out to do no work: a parent that never looked at the server never
saw anything to consider. It now directs the parent to discover the MCP first and
decide afterwards, against the real tool guidance rather than against a guess.
The second is saying accurately what this thing is. The parent was described,
and in the runtime guidance priced, as though it were specifically GPT-5.6 Sol at
high effort. It never was: the parent is model-agnostic, Sol is the creator's
example, and the worker/parent price relationship that motivated cheaper-worker
reasoning was one pair on one pricing schedule. That correction runs through the
tool descriptions, the schemas, the CLI and the documentation.
Alongside both: the activity view now covers a single delegation as well as a
batch, and rather less about a run is written to disk.
Install
npm install -g sol-luna-orchestrator
sol-luna-orchestrator initDiscovery, and what it does not promise
init installs a three-line managed block in the global Codex instruction file
Codex actually loads — AGENTS.override.md when that is non-empty, otherwise
AGENTS.md. Your bytes are preserved, a block you have edited is treated as
yours and left alone, status and doctor report whether the exact block is
installed, missing or modified, and init --no-discovery-hint opts out.
Fresh live sessions have been observed discovering the orchestrator and
consulting its guidance without the user naming this MCP or the word delegation.
That is manual, model-backed observation from a small number of runs on one
platform, and it is the strongest claim available here: a hint is guidance to a
model, and no MCP server can compel a parent to read it. The stronger wording
also does not push toward delegating — zero workers remains explicitly valid, and
a run where the parent sensibly worked solo is a pass, not a failure.
The related history is worth keeping straight, because it was previously
conflated: the benchmark runs where the model chose zero workers were routing
decisions taken with the tools named in the prompt, not discovery failures. See
Delegation Discovery.
A model-agnostic parent
Any compatible Codex parent with access to the configured orchestrator may
supervise. GPT-5.6 Sol at Medium is recorded as the creator's usual setting for
substantial repository work — an example, not a requirement, and not a
recommendation to run everything at High.
The runtime guidance no longer carries a fixed worker/parent price ratio.
Cheaper-worker economics are conditional on the selected parent actually being
priced above the worker under the current schedule, raw token counts are not
credit cost, more workers are not automatically cheaper, and this project has
never measured a realised saving. The one historical pricing observation that
motivated the argument is retained, labelled as such, in
Configuration.
Delegation semantics are unchanged in substance and clearer in wording: one
substantial bounded task can justify delegate_task on its own, sequential
batches are for dependent or shared-workspace work, parallel batches are for
genuinely independent tasks with disjoint declared scopes, and a batch's task
count is not its worker concurrency — that cap is now visible in the tool schema
so the parent cannot mistake one for the other.
Parent guidance also asks for silence while a call is pending and has nothing new
to report. That is guidance to the parent model and client. The server awaits
completion and cannot control what a client narrates in the meantime, so
compliance is something to confirm per parent and client, not something this
release enforces.
Watching a run
sol-luna-orchestrator activity now covers a single delegate_task the way it
already covered a batch: queued, started, verifying, completed, failed, cancelled
and timed-out states, with batch state, mode, active and total workers, elapsed
time and peak concurrency above per-worker blocks. An optional activityLabel on
the task contract names each worker in that view; without one it falls back to
Delegated task N.
Existing event files are treated as untrusted input on read. Every line is
validated against the known shapes, malformed legacy fields are dropped rather
than believed, and strings are stripped of control characters, so a hand-edited
or truncated file cannot crash the view or rewrite the terminal it renders into.
The reducer also tolerates out-of-order and non-ISO timestamps in older files.
Less written down
Objectives, worker prompts, task context, source code and verification command
output are excluded from the activity event stream, and task ids are opaque
rather than sliced out of the objective text — which also means worktree
directories no longer carry a fragment of the brief in their names.
This reduces exposure; it is not a privacy guarantee. The stream still records
working-directory and worktree paths, conflicting file names, concise failure
reasons and any activityLabel you supply, all of which can be revealing. The
diagnostic log is unchanged and remains the sensitive one: it holds objectives
and verification command output, truncated but not filtered for secrets. Only
control characters are stripped from either, which stops a crafted string forging
a log line and is not a secret filter. Observability and
SECURITY.md have the details.
Deterministic tests now supply their own event sink, so running the suite can no
longer append synthetic records to the activity history or diagnostic log of the
machine it runs on.
Unchanged
Worker scheduling, concurrency limits and defaults, the worker model, isolation,
declared-scope handling, verification policy and integration rules all behave as
before. Existing public schema fields and defaults also behave as before; the only
schema additions are activityLabel and the published batch maxItems described
above. Nothing here was measured to be faster or cheaper, and bench/RESULTS.md
is unchanged in its measurements: on small tasks delegating is still worse, and
no latency or token crossover has been found. Declared file scope is still
detective rather than preventive, verification still runs outside the Codex
sandbox with your permissions, and worktree isolation is still between workers
rather than between a worker and your disk.
Links
Keep every claim traceable to something measured or shipped. No performance or
cost claim belongs here that bench/RESULTS.md does not support.
v0.7.1
Release notes — working draft
This file stages the body of the next GitHub Release. It is not a record of
past releases:
- Shipped releases are recorded in
CHANGELOG.md, which is
authoritative. - Published release bodies live on the
Releases page.
Drafting the narrative version here rather than in the changelog means a release
body can be written and reviewed before the tag exists. Once a release has
shipped, clear this file back to the outline below: a copy of an entry that is
already published only drifts from it.
Currently in preparation: v0.7.1. This is a focused consistency,
supervisor-context-efficiency, and activity reliability patch.
sol-luna-orchestrator v0.7.1
What this release is for
This patch makes delegation guidance more concise and consistent with the
current bounded-work model, while making live activity monitoring more reliable.
Install
npm install -g sol-luna-orchestrator
sol-luna-orchestrator initChanged
- Substantially reduced supervisor guidance and repeated schema narration without
changing public delegation semantics. One bounded executable task, sequential
dependent work, and parallel independent work retain their existing roles. - Corrected implementation-only wording and aligned the README, worker brief,
tool contracts, contributor guidance, troubleshooting command, and annotated
configuration example with current behavior. - Clarified context and result-detail guidance so supervisors can send smaller,
task-relevant briefs and review returned evidence proportionally. - Made the MCP server advertise the package implementation version instead of a
hard-coded placeholder.
Fixed
- Fixed an
activity --watchstartup race that could miss events when the event
file was created and populated before the delayed watcher attached. File-change
processing is also serialized to avoid overlapping reads.
Unchanged
- Worker scheduling, concurrency limits, model routing, cost rates, verification,
isolation, scope checks, and public schema shapes/defaults are unchanged.
Links
Keep every claim traceable to something measured or shipped. No performance or
cost claim belongs here that bench/RESULTS.md does not support.
v0.7.0 - Context-Efficient Delegation
v0.7.0 - Context-Efficient Delegation
This release adds structured worker context and smaller routine delegation results.
Added
-
Context Capsule v2 (
contextCapsule)- Pass selected task-relevant context to workers through
relevantContext,interfaces,dependencies,invariants,upstreamDecisions, andknownPitfalls. - Empty and whitespace-only fields are omitted from the worker prompt.
- Existing delegation contracts remain backward compatible.
- Pass selected task-relevant context to workers through
-
Compact Evidence Packets (
resultDetail: "full" | "compact")- Routine delegations can request
resultDetail: "compact". - Successful verification stdout/stderr is removed from
structuredContent. - Failed, refused, and skipped verification evidence is preserved.
- Verdicts, discrepancies, scope violations, and
filesChanged[].whyremain available. resultDetail: "full"remains the default for compatibility.- Human-readable
content[].textremains unchanged between full and compact modes.
- Routine delegations can request
Supervisor behavior
The supervisor now prefers compact evidence for routine delegations and can provide selected Context Capsule fields when additional task context is useful.
Full evidence remains available when successful verification output is worth inspecting.
Validation
- 300 deterministic tests
- 299 passed
- 1 pre-existing Windows symlink-permission skip
- 0 failed
- Live Sol/Luna validation
- Parallel Context Capsule isolation verified
- Legacy full-result compatibility verified
- Compact failure evidence preservation verified
- Activity-event capsule privacy verified
Install
npm install -g sol-luna-orchestrator
sol-luna-orchestrator init
Links
- README: https://github.com/mahadansar/sol-luna-orchestrator#readme
- Changelog: https://github.com/mahadansar/sol-luna-orchestrator/blob/main/CHANGELOG.md
- Roadmap: https://github.com/mahadansar/sol-luna-orchestrator/blob/main/ROADMAP.md
- Security: https://github.com/mahadansar/sol-luna-orchestrator/blob/main/SECURITY.md
sol-luna-orchestrator v0.6.1
Release notes — working draft
This file stages the body of the next GitHub Release. It is not a record of
past releases:
- Shipped releases are recorded in
CHANGELOG.md, which is
authoritative. - Published release bodies live on the
Releases page.
Drafting the narrative version here rather than in the changelog means a release
body can be written and reviewed before the tag exists. Once a release has
shipped, clear this file back to the outline below: a copy of an entry that is
already published only drifts from it.
Currently in preparation: v0.6.1.
sol-luna-orchestrator v0.6.1
A patch release making live orchestration activity inspection work out of the
box after init, plus self-repair for existing v0.6.0 installations.
npm install -g sol-luna-orchestrator
sol-luna-orchestrator initWhat changed
In v0.6.0, sol-luna-orchestrator activity required manually exporting the
SOL_LUNA_EVENTS environment variable in your shell. In v0.6.1:
- Activity works out of the box.
initautomatically configures a local
event log path under your Codex home directory (~/.codex/sol-luna-orchestrator.events.jsonl). - Automatic path discovery. Standalone CLI commands (
activity,activity --watch,
activity --json,status,doctor) automatically resolve the configured event
path from your Codex configuration. No manualexport SOL_LUNA_EVENTSis needed. - Seamless repair. Existing v0.6.0 installations can migrate simply by
rerunningsol-luna-orchestrator init. It will add the missing event configuration
while preserving all existing settings. - Explicit path overrides.
init --events <path>allows choosing a custom
event file, andinit --log <path>now correctly updates an existing log path.
Custom paths you set manually are always preserved by plaininit.
Unchanged
- Event telemetry remains strictly local and private on your machine.
- Core orchestration, task contracts, verification, and benchmark conclusions
are unchanged.