Skip to main content

orion v0.12.0

October 7, 2026

Added​

  • An answered question continues the run that asked. When a run stops on a question and a person answers it, the next run now reuses the branch the asking run was on and keeps its commits, instead of cutting a new -2 branch and starting over. A retry of a failed run still gets a fresh branch. If the earlier branch is gone, the run says so and starts fresh. The run page says which run it continues (ADR 0039).

  • A split orion fan now shows on the run's page. The fan's note and its children's cost carried no run id, so a fan was invisible on the run page and History. orion fan now finds the run that asked (the newest run the log holds for the ticket) and stamps both with it; the stage's Details list the packages it was split across.

  • Start work lists the Jira backlog. A "Jira backlog" tab fetches a project's waiting tickets (status category To Do, epics left out, in Jira's backlog order, up to 100) and the tickets Orion failed, so you can pick some and press "Put in queue". That runs orion queue add (with --reset for failed ones), and when no watcher is running the page says nothing will work them and offers to start one. The web server holds no Jira credential: orion web hands it a lookup that reads the saved credentials on each request, so a token set under Settings > Connections works without a restart. Without Jira it says so and links to Connections.

  • A full live Activity stream on the run page. A new Activity tab in the right panel lists every tool call and remark of the selected agent as it happens, not shortened, following the newest while the run is live. "Everyone" widens it to the whole run, and "Wider" gives it most of the screen.

  • The project selector follows the ticket. Opening an LTA ticket while another project is selected switches the selector to LTA, instead of showing a project that contradicts the page. "All projects" is left alone.

  • A run parked for the batch is no longer called "probably killed".

  • orion web opens the new interface. The root now goes to the new front end; the old one is still reachable at /?legacy=1 until it is retired.

  • Connect Jira and Slack from Settings. A Connections tab sets the Jira site, account email and API token and the Slack bot token and webhook, into the same 0600 file orion config writes. A token is write-only: the page says it is set and where from, and never shows it again. Linear is listed as not supported, because the engine talks to Jira only. A saved token shows as dots that cannot be selected or copied (ADR 0038, accepted along with 0025, 0026 and 0027).

  • A logo for the web interface. The Orion constellation mark in the header and as the tab icon, which keeps its status dot (needs you, failed, running, idle). Source files are in docs/design/web/logo/.

  • The answer box warns when nothing will read the answer. With no watcher running, it says the answer waits in the inbox until one starts.

  • A run worked by ticket key shows on Needs you. A ticket that was never in a watcher's queue, such as one started from Start work, was filtered out; it now shows when its run is newer than the queue the watcher last published.

  • Stop a run from the web, from any page. A command started on Start work now shows on Overview and on its ticket page with a Stop button, so leaving the launcher no longer loses the way to stop it. Start work also lists tickets worked in the last 14 days, not only a watcher's queue, so a ticket you started by key is still there afterwards. A run that handed itself to a person with nobody to answer no longer says "a newer run has started" and links back to the same ticket; it says what happened (for example, that the branch was pushed and is waiting for the integration queue).

  • A run that ended blocked no longer reads as "working" for days. When the agent stopped without code, no advisor could answer its question and Orion wrote "blocked", the run page kept showing "Implementing, Working" and, later, "its process was probably killed". It is now over, shown as stopped, and its question appears on Needs you.

  • orion plan KEY is one resumable chain, and spec-kit runs inside it. The chain is now toolkit → intent → constitution → spec → plan → analyze → scaffold → remote → decompose → release → clone, and it ends at next: orion watch KEY with nothing left to type. Three steps are new: constitution writes .specify/memory/constitution.md through /speckit-constitution, seeded from orion.json's gates and branch model and the intent's constraints, and fails while a template slot is left; analyze runs /speckit-analyze read-only and Orion reads its Critical Issues Count itself — above zero, or missing, blocks the chain; release (--release vX.Y.Z, opt-in) creates the version and attaches every ticket in the tree. remote and clone moved into the chain from their own commands. decompose creates the tree natively when the plan stage left a tasks.md, stamping the ORION queue label on stories and epic-level tasks — the levels orion watch claims once each — and falls back to /pm-plan otherwise.

  • A second orion plan KEY resumes. Every step derives whether it is done from its own artifact and is skipped with = done; a killed chain picks up at the first unfinished step. --from <step> re-runs from a step on purpose, which is also how a re-plan works: edit the spec, --from spec. task.json is written atomically.

  • The discovery gate reads spec-kit's own markers. A [NEEDS CLARIFICATION: …] anywhere in the spec blocks plan, analyze, scaffold and decompose until a person replaces it with the decision; orion answer lists them beside the intent's questions. The orion preset Orion installs into every spec-kit project makes /speckit-specify write every uncertainty as a marker — no best guess, no cap, no interactive questionnaire a headless run cannot answer.

  • orion answer asks. On a terminal it walks every open question — the intent's bullets and the spec's [NEEDS CLARIFICATION] markers — one line each, - to skip, ? to record "unknown, design for it", and writes each answer into the file where the gate and every later stage read it, then commits. Off a terminal it lists them as before.

  • orion doctor checks spec-kit's version. It resolves every toolkit.stages command to a file on disk and fails naming the stage when one is missing; it reads specify version --features --json, prints the installed version beside the release Orion pins (v1.0.4), and names the reinstall line when a required feature is absent.

  • orion web has a new interface at /next/, and a person can answer from it. React and Fluent UI, light by default with dark, system and high contrast, served beside the old page (which is unchanged) with the build embedded, so go build needs no Node. It shows the board as a pipeline and the queue's dependency graph, a Needs you list, a ticket page, History by project and ticket, and a run page that draws the work as a graph with a threaded conversation. A ticket waiting on a person takes an answer there: it goes to an inbox under ORION_HOME/answers, and the watcher posts it to the ticket and requeues it on its next pass, saying where the answer is until then. Limits, collect settings and the agent roster can be edited there too, through the same tables orion config uses, and the page refuses values above a confirm threshold. A run waiting on a batch says whether it is assembling, in CI or landing, and a landed ticket records its merge. Every write needs the per-process token, an allowed origin and an allowed host. It cannot create a project yet.

  • orion web can clear a gate and start work, through a closed list of commands. Needs you is the gate board of the design: tickets grouped by project, with views for waiting on me, in flight, everything and by batch. A ticket waiting for a merge approval has Approve and Request changes buttons that show the exact command first; Start work picks tickets, shows who each routes to, the command and what it spends, and runs orion work, orion queue add or orion watch, with a stop button. The page never sends a command line: the server builds it from a fixed table, re-checks the ticket at request time, refuses a start when the weekly budget is spent, and stops what it started when the server stops. A recommendation waiting for confirmation is a gate too, with Confirm plan and Request changes. A Projects page shows each project's GitHub page, tracker page, local path and channel; the tracker page and channel can be edited there (the working copy and git remote cannot), a project can be created from a form and planned from the page, and the project chosen at the top scopes every page, including Settings, and is carried in the link. The Overview shows the batch being landed: its phase, CI against the usual time, and each ticket's state. A run that never recorded an end and has been silent for 45 minutes is shown as stopped, not running. The pages fit a phone.

  • orion plan KEY --yes runs the whole planning chain with no terminal. Without a terminal orion plan used to provision, announce and stop, because nobody could answer its pauses. --yes answers every pause itself, so a script or the web page can plan a project unattended; it creates the GitHub repository and files the ticket tree like an interactive run does, a step that needs a free-text answer fails instead of guessing, and at a terminal --yes changes nothing.

  • orion new --answers FILE creates the tracker project from answers in a JSON file. The same questions, description, permission check and confirmation as the interview, with no terminal needed, so a form can drive it. The project name must be given again as confirm_name and match exactly, or nothing is created (a tracker project cannot be deleted without admin rights); unknown fields and questions, control characters and oversize files are refused, and the idea is taken as written: it is never read as a file, a URL or a tracker key.

  • orion approve KEY and orion confirm-plan PROJECT RECORD record a decision without a Slack reaction. Add --reject --reason <text> to refuse. They are read by orion collect and the stage that asked with Slack's, under the same rules: a rejection beats every approval, and nothing is decided for a ticket Orion has not asked about. An approval is refused until collect.allow_local_approval is true in the project's orion.json (off by default, and not editable from the web); a rejection is always accepted. Neither merges anything: the next collect pass does, and the commit names who approved.

  • orion plan asks which organisation to create the repository in. When no --org was given, the remote step lists your GitHub account and every organisation you belong to, and creates the repository under the one you pick — by number or by name; enter keeps your own account. The choice is recorded, so a resumed run creates the same repository without asking again. A non-interactive run, an account in no organisation, or an org list gh cannot read keep the previous behaviour: your own account, no question.

  • The watcher retries a failed ticket itself once the work branch has moved. A ticket that failed for a reason outside its own code — CI or the sandbox missing a dependency, a module a sibling ticket had not landed yet, a conflict with work that landed after it started — used to sit in orion-failed until someone relabelled it. The watcher now records the work-branch head when it first sees a ticket fail and, once that head has moved, requeues the ticket to run again on the new base: at most twice per ticket, after which it is named to a person. A ticket failed for a missing prerequisite is therefore held until something lands, never retried against the base it already failed on.

  • orion watch can ship its events to your observability backend. Off by default; turn it on in ~/.orion/observability.json. One OTLP exporter with presets for Grafana Cloud, Datadog, Dynatrace, New Relic and Honeycomb, plus Loki's own push API for a self-hosted Loki before 3.x. Credentials are read from environment variables named by the preset, never from the file. Grafana Cloud:

    {"enabled": true, "preset": "grafana",
     "endpoint": "https://otlp-gateway-<zone>.grafana.net/otlp/v1/logs"}

    with GRAFANA_CLOUD_INSTANCE_ID and GRAFANA_CLOUD_TOKEN set; query {service_name="orion"} in Explore. Events carry project, ticket, actor, model and verdict; tool-call events are left out unless include_tool_events is set. Shipping never blocks the watch: a full buffer or a refusing backend drops events with one warning, and anything credential-shaped is scrubbed before it leaves the machine.

  • A person's comments on a ticket reach its agents. The three most recent comments a person wrote -- not Orion's own -- are added to what the implement, QA and case-analyst prompts read, under "NOTES FROM A PERSON ON THIS TICKET". To steer a re-run, comment on the ticket and requeue it; there is no need to edit the description.

Changed​

  • spec-kit is installed per project, and its command names now resolve. A new workspace's orion.json named /speckit.specify and /speckit.plan with a dot, which is spec-kit's README prose; its Claude integration installs speckit-specify and speckit-plan with a hyphen, so no stage command ever resolved and every new project silently ran the built-in prompts. The names are corrected everywhere Orion writes or reads them. A raw clone of spec-kit is not an install and is no longer treated as one: specify init --here --integration claude inside the workspace repository is, and orion doctor now grades a toolkit installed there instead of warning that a run cannot reach it. The decisions behind this — spec-kit's commands run inside Orion's stages while its workflow engine, extension hooks and bundles are declined; installation is per project; a spec is a living document — are ADRs 0021, 0022 and 0023. The chain steps that use them land under OR-355.

  • orion watch shows a status board instead of a scroll of repeating lines. One block — running tickets with their stage, elapsed time and last action; the queue (ready, blocked, in CI, failed, landed, spend); the batch in flight with its pipeline and check states; the last batch result; and a "needs you" line only when something requires a person — printed when it changes, and at most every few minutes while work runs. It replaces the per-ticket heartbeat every 30 seconds.

  • Fan-outs and subagents appear under their ticket. A fan's children are a tree on the board (done with duration, running, failed, queued at the concurrency limit); the scroll keeps one start line, a failed child's reason, and one closing line. A run's own subagents show as a count on its row.

  • Held and retry-waiting tickets print when they change, not every minute.

  • Failure and warning lines are never cut to the terminal width, so a red suite names what failed.

  • Each ticket has its own person within a role under a watcher (a small roster per role, kept for the ticket's whole life), in event lines, the board and tracker comments.

  • A local build from develop reports the last release, e.g. v0.11.0+dev.<sha>, instead of an old tag.

  • The CI fix loop is on by default (ci.auto_fix). A red build — including a ticket a batch convicts — goes back to the agent on its own branch instead of orion-failed and a full re-run from scratch. It stays bounded: three attempts by default (ci.max_fix_attempts), and it stops at once when the same failure repeats. A project that sets auto_fix: false keeps it off.

  • orion watch on a terminal is now a full-screen view, like top. The board stays at the top and the newest log lines fill the rest, redrawn once a second, instead of the board being printed into the scroll every few minutes. Because the full-screen view has no scrollback, every line is also written to ~/.orion/logs/watch-<time>.log, and the header shows the path. On exit the normal screen comes back with the last 30 lines on it. Use --plain to keep the scrolling log; a pipe, --once and --dry-run keep it automatically.

  • The in-progress icon on the orion watch full-screen view now turns, the way orion plan's live line does, so a running ticket, fan-out child, batch step or pending check visibly moves. The plain log is unchanged.

  • The orion watch full-screen view puts its header and board on a dark panel, labels each section (RUNNING, QUEUE, BATCH, CI, LAST, NEEDS YOU) with a chip, and brightens text colours that would be unreadable on the dark background. The log below keeps the terminal's own colours. Plain when NO_COLOR is set.

  • The orion watch full-screen view has two fixed panels with the log between them: running tickets, the queue and NEEDS YOU on a panel at the top (dark under the default theme), and the batch, its CI checks and the last result on a grey panel pinned to the bottom. With no batch to show, the log takes the space.

  • The orion watch full-screen view is redesigned. Colour now means state: every section label is one slate chip and only NEEDS YOU keeps magenta. The header sums up the watch (running, queued, landed, failed and the spend) with the clock at the right. RUNNING is an aligned table of ticket, stage, elapsed time, who and what it is doing. A fan-out folds to a progress bar in its row and shows its tree only when a child fails. The bottom panel shows how long each batch step took, and CI's progress against its usual time. Set ORION_THEME=light for a light terminal or ORION_THEME=mono for no colour (NO_COLOR implies mono). The waiting icon is now ◷, one cell wide on every terminal.

  • Every row of the orion watch log is one grid, and ok is gone. Each row is TIME · TICKET · STATUS · WHO · MODEL · MESSAGE. The vague ok is split into done (a step finished or a check passed), skipped (deliberately not run, with the reason), sent (a person or channel was told) and setup (a branch, route or sandbox was made). A ticket starting is one start row, a stage boundary is a stage row with the transition as its message, and a setup notice is a note row. The worktree path row is gone; the branch row names it. working, waiting, warning and failed are unchanged.

  • QA tests only its own ticket, and never writes a credential-shaped literal. The QA run, each fan-out author and the developer fixing QA's findings are told to skip -- naming the ticket -- any claim that depends on another ticket's unlanded work, and to build fake keys at runtime ("AKIA" + "X" * 16) rather than write a string a secret scanner cannot tell from a real one.

  • A CI failure Orion will retry is a Slack heads-up, not a page. While retries remain, the notice reads "KEY failed CI -- Orion will retry it (N of M retries left)", at warning level and with no mention. Only once retries are spent does it page: "KEY still fails CI after N retries", with the fix-or-requeue instructions. A batch conviction is described as one ("It failed in a batch …") rather than as the branch failing on its own. The old notice told everyone the ticket was never re-queued automatically, which stopped being true with the automatic retry. orion collect run by hand still pages, since it never retries.

  • The orion watch full-screen view is one framed window. A rounded border runs round the whole screen with the title and clock in its top edge, and rules join the top panel, the log and the bottom panel. Section labels are set in from the edge and centred, with a space before the row they head. Under ORION_THEME=mono or on a terminal without Unicode the frame is drawn in + - |. The frame costs four columns and three rows. The grey bottom panel now keeps its colour to the end of its last row.

Fixed​

  • A watcher whose queue is stuck behind failed tickets now says which ones. Once everything left in the queue depends on a ticket labelled orion-failed, nothing can start until it is retried. The watcher used to print only "blocked by" lines and, an hour later, stop with "achieved nothing". It now names the failed tickets it is waiting on, with how to requeue them, on each idle pass and in the stop message.

  • A project created by orion plan now posts to its Slack channel and lands work in batches. The plan chain made the project channel but left slack.enabled false, so every run said "slack is disabled in orion.json" while the channel sat empty; it now turns Slack on whenever the project has a channel, and says in the plan output when there is none. The orion.json it writes for a new project also turns on collect.batch_integration, so finished tickets are merged and tested together in one CI run instead of one pull request each. An orion.json that already exists keeps its own setting.

  • A project orion plan creates is no longer red on every branch for reasons none of its tickets caused. Found on a Python project:

    • The CI workflow was written before the scaffold stage created pyproject.toml, so it installed no Python and every run failed with "No module named pytest". A workflow written for a project whose toolchain is not yet known now chooses it when it runs, from the marker files on the branch, and one Orion wrote that way earlier is upgraded in place — only when it is byte-for-byte the file Orion wrote, never one a person edited.
    • The secret scan read every fetched branch's history, so one branch holding a finding failed the scan on every run in the repository and batch isolation blamed tickets that never touched the file. It now scans the full history of the branch under test only; an earlier generated scan workflow is upgraded the same way.
    • The sandbox's virtualenv was built only by orion init, so in a project created by orion plan QA could not run the suite and fix rounds were spent building one. Every ticket run now prepares it first (a no-op once it is current).

  • "QA gave no verdict" is shown as a warning, not a failure. The ticket continues to CI and review by design; printing "failed" and then "ready for the next batch" read as two outcomes for one ticket.

  • orion watch KEY lands only its own project's work, and a project's batch is never built from another project's config. The watcher limited what it started to the projects it was given, but reconciled every registered project's tickets waiting on CI. When that pass mixed two projects, the batch used the first project's workspace and config and the second project's tickets were skipped entirely — orion watch LTA spent its passes on a Continuity batch and never landed an LTA ticket. The watcher now collects only its own projects, and a pass that spans several (orion collect, or orion watch with no key) is reconciled one project at a time.

  • Tasks the task list says to run in order are now run in order. In a spec-kit task list only tasks marked [P] may run alongside each other; a task without it runs in phase order. orion decompose recorded the marker in each ticket's description but created no ordering link from it, and the queue orders by links alone — so a whole phase could be claimed at once. Tasks that import each other's modules then each wrote their own copy, and their branches conflicted or failed on the missing import. Decompose now links each run of tasks to the run before it in the same phase. Tasks inside a story are unaffected (a story is worked as one unit), and re-running orion decompose adds the links to an existing tree.

  • QA in a ticket's worktree tests that ticket's code, not the work branch's. The sandbox virtualenv has the project installed from the main checkout, and every worktree shares it — so in a Python project with a src/ layout, the generated scripts/test.sh imported the main checkout's copy and QA could report "verified clean" on a change it never ran. The script now puts the tree's own src/ first on the import path. CI was never affected.

  • Re-running orion decompose on a large tree no longer creates duplicates, and it applies ordering added since the first run. The lookup of what a previous run created read only the first 100 tickets, so on a 150-ticket tree a re-run offered to create the other 50 again. It now reads every page. And a re-run with nothing new used to stop at "nothing to do" before applying any ordering link; it now offers to apply the tree's links, adding only the missing ones (Jira keeps one link per pair).

  • orion watch starts with a five-line banner instead of ten, and nothing in it wraps mid-word.

  • A local build is no longer offered the release it was built after. A build from develop is versioned v0.11.0+dev.<sha> (build metadata), not v0.11.0-dev+<sha>, which semver sorted before v0.11.0.

  • The watch board reads correctly under a red batch. A failed check turns the batch red and its CI step shows ✗; "went red" prints as a failure, not a warning; an ejected ticket leaves the member list and shows as "ejected, next batch: KEY (conflict in FILE)".

  • Blocked tickets are grouped by blocker on the board ("12 on LTA-30 · 10 on LTA-137"), queue counts add up (waiting · in integration · landed · failed), long key lists in the scroll shorten to "first … last (N tickets)", and the board's rules span the terminal.

  • Stopping orion watch says what it is waiting for, and a forced stop cleans up after itself. The first ctrl-c now names each running ticket with its stage and how long it has run, prints a line every minute while it waits, and says "stopped" only once the last agent has finished — it used to say "stopped" immediately and then wait in silence, sometimes for hours. A second ctrl-c still kills the agents, and now also puts their tickets back in the queue (removes orion-working and the stage label) instead of leaving them claimed for a person to clear. The tracker gets ten seconds; any ticket it could not release is named.

  • A batch that went green after a watcher restart no longer shows "CI ◐" on the board while it lands.

  • A green batch that GitHub will not rebase now lands. A batch whose members carry merge commits (for example a conflict resolved by merging the base in) was refused on every pass by the rebase merge and never landed. Orion now lands it as a merge commit when rebase is refused.

  • orion watch prints collect errors. They were dropped, so a failing landing showed only "in integration" with nothing saying why.

  • The orion watch board no longer reads "ended without a result" after a batch lands on a later tick; it names the tickets that landed. A hold for shared files now reads "N sharing files with KEY" instead of overflowing the QUEUE row.

  • A ticket whose branch was left out of a batch is no longer closed as delivered. When assembly ejected a branch on a conflict, the batch still recorded it as a member; the landing then closed the ticket and its sub-tasks although its work never reached the base, unblocking tickets that depend on it. Only branches that actually merged are now landed and closed, and an ejected branch is named in the log with the reason.

  • Landing a story no longer closes its HUMAN-marked sub-tasks as delivered. Work the task list marks as work no agent can do is never offered to the queue, so nobody has done it when the story merges -- closing it stated something false and released whatever was linked behind it. Those sub-tasks now stay open, and the landing comment on the story names them ("LTA-30 is a person's task and stays open"). Every other sub-task closes as before.

  • A landed ticket's worktree is pruned even when the Continuity plugin left untracked session notes in .continuity/; they no longer count as uncommitted work. A committed .continuity/ file is still protected.

  • orion watch names, under NEEDS YOU, every blocker that holds queued tickets but is not in the queue itself (a HUMAN task, or a ticket without the queue label), with how many tickets it holds. The board used to show the whole queue blocked with NEEDS YOU empty.

  • QA's derived test-case list is capped at 40. The case analyst once returned 803 lines -- the real cases, then hundreds of filler lines -- and QA would have fanned all of them out to five authors. The prompt now asks for at most 40, most important first; anything past 40 is dropped with a warning saying how many.

  • A red base convicts nobody. When batch isolation finds every member guilty, one more CI run tests the work branch alone. If that is red too, the failure is outside the batch -- a check failing on everything, such as a secret scan reading every branch -- so no ticket is convicted and the batch is recorded as stuck instead of sending sound branches into the fix loop.

  • A failed ticket is retried as soon as a batch lands. The automatic retry waits for the work branch to move, and read the branch from a clone nothing had fetched since the batch landed through the forge -- so failed tickets waited for a move that had already happened, and the no-progress breaker stopped the watch an hour later. The branch is now fetched before the check.

  • A landed ticket leaves the board, and its retry branch is pruned. A ticket whose CI failure was fixed by the fix loop stayed on the board as "starting" after it landed, because only the watch's own dispatch ever ended a row. The fix run now ends its row, and a landed batch member leaves the running rows. Landing also prunes the branch the ticket actually worked on (orion/<key>-2 after a retry), not one rebuilt from the key, so the worktree no longer stays behind.

  • "blocked by" in the middle of a sentence is not a dependency. A ticket whose text said it should "record which scenarios are blocked by an open question" was held all day as an unmapped dependency, which nothing can ever satisfy. A dependency phrase that names no ticket key now counts only where a dependency line starts (Depends on: server skeleton, - Blocked by: design sign-off); one that names a key still counts anywhere.

  • The CI fix agent reads the log of the run that failed. It took the newest run of any workflow on the ref, and a batch ref runs two -- tests and the secret scan -- so it could be handed the green scan and report that it could not see the failure. It now takes the newest run that failed.

  • Slack setup hints name the token Orion actually reads. orion slack test and the missing-scope message told you to run orion config --only ORION_SLACK_BOT_TOKEN, but Orion reads ORION_SLACK_TOKEN. Following the hint stored the token under a dead name and Slack stayed "not configured". Both hints now name ORION_SLACK_TOKEN, and orion config --only refuses a name Orion never reads and lists the ones it does.

  • The production-deploy gate no longer reads quoted text or a heredoc body as a command of its own. A \| inside a grep pattern, or one line of a file being written with cat > file <<EOF, used to be cut out as a separate "command" and blocked for containing the words "prod" and "deploy". Separators inside quotes now stay part of their argument, and a heredoc body is judged together with the commands on the line that opened it. Text a shell or interpreter will run is still judged: bash <<EOF, cat <<EOF | sh, python3 - <<EOF and sh -c "…; ./deploy.sh production" are still blocked.

  • A forced stop really puts tickets back in the queue. A second Ctrl-C on orion watch said each killed ticket was "back in the queue", but only took orion-working off. The claim had already removed the queue label, so the ticket was left with no Orion label and still In Progress, and nothing picked it up until a person re-labelled it. The release now puts the queue label back in the same write and returns the ticket to To Do.

  • orion doctor no longer recommends --container. On a machine without an OS sandbox it told you to "use --container", a mode no command accepts any more. It now names a route that works: check that sandbox-exec is present on macOS, install bubblewrap on Linux, or run Orion on macOS or Linux (for example under WSL2). The README and USAGE no longer point to the flag either.

  • orion queue shows tickets waiting for their batch. A ticket on the ready shelf (orion-ready) was fetched but never listed, so finished work waiting to land was invisible in the one command meant to show the queue. It now has its own "ready" group and count. orion queue add and orion queue remove also refuse a ready ticket and say why, instead of quietly adding the queue label to work that is already finished.

  • The deploy gate no longer blocks a file write that shares its line with a variable assignment. S=/dir; cat > $S/f <<EOF was blocked when the heredoc's text mentioned production and a release, because the text was judged against S=/dir as if the assignment were a command. A segment that only sets variables is now treated as running nothing. An assignment in front of a command (FOO=1 ./deploy.sh production), or one that runs something (X=$(...)), is still judged.

  • Stopping an agent reaches every process it started. Orion killed an agent's process group with a single signal. A process the agent was starting at that exact moment could miss it, keep running on its own, and hold the agent's output open, so a forced stop reported the agent as still alive and a timed-out run could hang. Orion now signals the group again until the agent is gone.

Download v0.12.0 · Staying current