BOSS Community v1.0-rc10.13

BOSS Community 1.0.0-rc.10.13 candidate

RC10.13 is the public main after v1.0-rc10.12. It keeps that candidate's project experience and local-first work, and adds the tool-call controls and the git-style change review that landed after the tag.

This is a test candidate. Cutting the tag does not deploy a host, publish an image, or re-run the release gate.

What changed

Tool calls

• A held call stores args_sha256 and a redacted preview. Resume refuses when the pending arguments differ. The decision card shows that preview, including the exact [redacted]. The receipt refuses before it calls the tool when the approved decision has a digest and the arguments differ. A decision with no digest still runs (BOSSAPP-816). The HMAC signature is not in this candidate.
• Tool results are screened for instruction-override phrases. The tool text is kept. A hit turns the next write from allow into ask (BOSSAPP-822).
• A reachable probe stores schema and description hashes. A same-named tool whose hash changed is stored as ask, and one decision is opened. An unreachable probe does not (BOSSAPP-818).
• Each receipt-path tool call is appended once. Update and delete are rejected. One project's rows list newest first (BOSSAPP-819). There is no HTTP export in this candidate.
• An always-allow row can be granted, listed, and revoked. The live allow/ask/off read is unchanged (BOSSAPP-817).

Review and local projects

• The change page reviews a local change the way it reviews a GitHub pull request, including comments, request changes, and publish (BOSSAPP-948, BOSSAPP-954).
• A local project deploys from its own repository. A preview keeps its own origin (BOSSAPP-946, BOSSAPP-947).
• Setup can add a GitHub account (BOSSAPP-945).

Decisions and checks

• Keyword decision eval is checked in. Model rows print not measured (BOSSAPP-580).
• A drafted typed decision is a real branch with on_true and on_false (BOSSAPP-581).
• Ordered tool rules run before the build loop (BOSSAPP-815). The database policy table, scopes, and rate limits are not switched on here.
• Official verify uses the shipped working directory (BOSSAPP-953).
• The install template states that microVM claims stay frozen (BOSSAPP-950).
• The always-on agents ship on. Off is one Govern choice, or BOSS_AMBIENT_COS=off.

Checks

• The version pins match 1.0.0-rc.10.13 (engine/tests/test_distribution_contract.py).
• The tool-call slices were tested on disposable databases before they landed. This tag was not installed on a clean host, and the release gate was not re-run.
• EXPORT_CANDIDATE_STATUS.json still cites docs/community/RC9_VALIDATION.md.

Known gaps

• Knowledge-graph pull requests #11–#15 stay open.
• HMAC for a held call, the tool catalog table, the audit HTTP route, and switching the live policy read to the always-allow rows stay open.
• A live image tag, live URL, and release-gate JSON are not part of this tag. Plane issues that wait on those stay In Progress.
• Paperclip gaps (BOSSAPP-812) and Kiro gaps (BOSSAPP-934) remain open.

BOSS Community v1.0-rc10.12

BOSS Community 1.0.0-rc.10.12 candidate

RC10.12 builds on rc10.11. It brings the project experience (one page per project, New work, onboarding agent, Needs you), a rebuilt Add a project with two doors and local-first projects you can build on this machine and publish to GitHub later, Where people decide (the 7 decisions only a person makes), Add a server, Watch this app, Delete project, a larger type scale, and many fixes to the always-on agents. It also carries Sean's console polish and hardening from main, with three production-build fixes for it.

This is a test candidate.

What changed

Projects

• One project page: Overview, Work, Roadmap, Repo & knowledge, Deployments, Health and Settings, with a journey diagram, Needs you and the Captain (BOSSAPP-913/914).
• New work as a small dialog: Helm reads your request into a Task, picks the workflow, priority and estimate, and can chat before you start.
• Add a project has two doors: Start a new app, or Bring existing code (BOSSAPP-916). A new app gets a Project brief; existing code gets a Repo summary. Every button is covered by a browser test.
• Same repo, same project: choosing a repo that is already a project opens it, offers "Add work there instead", and makes a second project only after one confirmation; the API refuses a duplicate otherwise.
• Delete project with a full cleanup in one transaction (every row, its knowledge graph, previews and staging apps, local repos and work files); the GitHub repo and the audit log are kept. Type the name and confirm with your passkey.
• A repo with several apps: Roadmap and Repo & knowledge show this project's app first; other apps sit under "Elsewhere in this repo" (BOSSAPP-931).
• PRD approval shows the PRD, links the meeting where the panel debated it, and commits it to the repo as docs/prd/<name>.md (BOSSAPP-929).

Local-first (BOSSAPP-915)

• Build on this machine: BOSS keeps a git repo per project; builds commit locally, review and merge happen in BOSS, and previews and staging deploy from the local repo.
• Publish to GitHub later: history, branches and open changes (as PRs); safe to re-run.
• GitHub outages: a build keeps its work locally, shows "Waiting for GitHub" instead of failing, and pushes when GitHub is back.
• Import code from a folder on this machine or a host, keeping its history.
• BOSS can create the GitHub repo for a new app.
• Backup and restore include the local repos.

Governance and agents

• Where people decide replaces Govern › Autonomy: production deploy, merge to the default branch, spend above the cap, secrets, outside messages, deleting data, and who can do what. Rules can only get stricter; quiet windows and backup deciders really hold approvals; change a rule in plain words.
• Decisions only a person makes never silently expire; a merge question whose PR is already merged or closed withdraws itself.
• Merges are idempotent: merged state shows everywhere at once, a retry updates the open PR instead of opening a second one, a fix after a merge is a named follow-up, and a failed merge says why.
• Always-on agents: cards name the work and their buttons do what they say; squads read with their role's tools; work waiting on a person is parked; nothing waits forever; spent budgets ask a person; nudges run on their own.
• BOSS reads its own upgrades and restarts (install_restarts), so the infra squad can tell an upgrade from a crash.

Infrastructure and monitoring

• Add a server: one input, one hand-over of access, and the Infra agent sets it up and watches it. A server gets a role, never an app.
• Watch this app on Project › Health, wired to the app's alert rules, contact points and the incident flow.
• Deployments tell the truth: an address is live only after a successful deploy; a running deploy shows its steps and logs live, with Fix and Roll back (BOSSAPP-930/932).

Console

• Type scale raised to match Workflows (body 14px, small text 13px); a test fails any hard-coded font size.
• Popovers open fully visible on every screen size.
• Confident headings: Project brief, Repo summary, Task, Agent actions.
• Console polish: without a reskin (BOSSAPP-899), plus hardening fixes: inbox cards for capacity failures and rules 403s, OIDC body caps, conversation streams, permission declarations, receipt double-spend.
• Fixed here: two CSS-module :root blocks and three colour tokens cut mid-expression stopped the console image from building.

Installer and release gate

• Upgrades on installs older than 30 days: the post-start check and rollback use the host key, not the retired shared key.
• The app-start proof uses its own port; a manifest's PORT no longer overrides it.
• The gate checks local-first without reading the install's .env.

Checks

• Release gates: plumbing 20/20, engines 15/15, one real agent build (see below).
• Type check clean; key API suites pass; the web suite has no new failures against main (known failures are tracked in BOSSAPP-944).
• Installed and smoke-walked on a laptop with real projects.

BOSS Community v1.0-rc10.11

BOSS Community 1.0.0-rc.10.11 candidate

RC10.11 builds on rc10.10. It brings the new console flow (Welcome, Repo and models, New project, Govern › Spend), several GitHub accounts per organisation, deploys that wait for their merge, shared hosts across an organisation, the knowledge-graph case studies (banking regulation, AML, data quality), Sean's low-trust containment and egress fixes, and a preview of autonomous agents that ships off by default.

This is a test candidate.

What changed

Start, set up and sign in

• A 3-step Welcome, then one Setup page for GitHub accounts, repositories and models (BOSSAPP-808). Advanced keeps every option; Budget lives in Govern.
• Several GitHub accounts in one organisation. Each account has its own token, and a build uses the one that covers its repository.
• One "Connect GitHub": your own GitHub App in two clicks, with access that does not expire (815).
• New project has three doors, including Import a repo, and a project page (BOSSAPP-810). A feature for an imported repository changes that repository's code.
• Password first, passkey on request. A passkey is never the only way in (812). A fresh install can be claimed on its own site from a private network (813), and claiming never asks for the shared console password.
• Claude sign-in works the first time. The installer writes the secret store's master key, and the first press after "Confirm it's you" no longer says "Reload and retry" (897).
• Models: one menu per job, with a Subscription or API key choice for Claude Code and Codex. A model only runs on an engine of its own family.

Govern

• Govern opens on Spend, with one "spent" figure on every screen, spend by project and per-project monthly limits enforced at reservation (BOSSAPP-807). Pace is the first card on Limits.

Builds, merges and deploys

• A deploy waits for its pull request's merge. The step says so, links the PR, and needs you until GitHub shows it merged. A merged build deploys its merge commit, not the head pinned before the merge.
• BOSS can merge an approved pull request when the install turns it on (BOSS_ENABLE_SANDBOX_MERGE). It merges the PR's own repository. In a repository without CI it goes ahead on BOSS's own checks, and a merge that could not run fails its job.
• Shared hosts. A verified host is usable by every project in its organisation, and its page opens from each of them. A second app with the same name on a shared host gets its own place.
• Compose secrets. A deploy generates the session keys its app's compose file reads; previews get the session secret too. Setup › Demo logins shows the password an imported project's deployed app runs with.
• Faster repairs. An approved PRD is the build's design (a short mapping pass, not a second design session). A repair's review and consistency check judge only what the repair changed.
• A browser suite runs where its config is. A step whose work finished while the run was stopped ends when the work did.
• Run report: Open report shows the whole report in a dialog, every section open.
• Every build is reviewed, whatever its tests say, and review findings are P1/P2/P3. One warm sandbox per build lineage; retries resume at the failed stage.

Knowledge graph and case studies

• Rulebooks into the Knowledge Graph: upload with a confirmed split, DQ rules from clauses, embeddings, citations and neighbours.
• The banking regulation, AML alert investigation and data-quality (DQ) pipelines run end to end on real projects, with role agents, person gates and a per-step graph trace. A bank's own outside agent can run a pipeline step under BOSS's contract.
• Domain and Context layers on one canvas, with stored decision edges.

Safety (Sean's public-line fixes)

• Low-trust containment, the sandbox network fence fails closed, and egress reports the truth.
• The build agent's tools are checked, the installer recovers its own source, and the GitHub App update callback works.
• Release approval cards, alerting display fixes and console route fixes.

Autonomous agents — preview, off by default

• What it is: BOSS notices problems on its own (alerts, red CI, advisories, cost spikes, a new repository's dossier). A Chief of Staff agent triages each one into a single work item, and squads work it together on a shared board. The squads include an AI SRE incident squad. Every decision is on a ledger, every action goes through the autonomy gate, and continuous learning feeds a Recommended roadmap. In the console, Agents at work shows each item as a flow chart.
• It ships off. The operator has not reviewed it yet, and the browser walk has not run. With nothing set, the worker does no signal sweep, no triage, no squad turn, no automatic dossier and no learning tick.
• You can still look at it. The Agents at work area shows. On a demo project (its name says demo, sample, sandbox or test), Load demo loads four stories through the real machinery. Triage now runs once, and asks you before anything is handed to an agent.
• To turn it on, set BOSS_AMBIENT_COS=propose in the install's .env and restart the API and worker. With propose, every handover asks a person first. route hands A2+ classes straight to their squad. BOSS_AMBIENT_SIGNALS=1 and BOSS_AMBIENT_LEARNING=1 run the sweep or the learning tick on their own. BOSS_AMBIENT_DISABLED=1, Stop all and a project's Stop win over everything. See AUTONOMOUS_AGENTS_SPEC §0.

Validation

• P0 plus the tests of the changed areas, one file at a time against boss_test:
  • 485 Python test files (417 engine, 56 API, 12 worker): 7,376 tests passed.
  • Eight failures were new on the combined branch and are fixed in it: a real server address in three comments, the meeting-title and run-reach guards, the one-gate scan for the merge wait, the browser-suite pass, the checks-failing wiring test and the identity route matrix.
  • Every other failure also fails on origin/main, or passes on a clean test database (the shared database's leftovers).
• Narrowed API coverage. API files that only import a widely shared module were cut after 21 of them ran, to keep the gate within hours. API P0, every API test the merges added or changed, and every API test touching ambient, deploy, merge, host, kit or release planning code all ran.
• The console: tsc --noEmit is clean. 218 vitest files ran: 3,144 tests, and one new failure, fixed (the Run group now lists Agents at work). The other 14 failures also fail on origin/main.
• The plumbing e2e gate (scripts/e2e-gate.sh plumbing) passed 16 of 19 checks. The same 3 fail on origin/main in this environment: the app-start proof, and the connector and optional-settings checks that depend on it. The app listens but does not answer HTTP within 90 s.
• The engines e2e gate (scripts/e2e-gate.sh engines) passed 15 of 15 checks.
• The real-agent build gate: two HelpDesk AI Demo runs on the operator's laptop on 2026-11-06, wfr_07e8e723b44f445c9656 and wfr_2adddafc003f4533adb3. The first went brief → build → PR → merge by BOSS → deploy → a healthy app.
• Pre-existing failures (also on origin/main):
  • the public-tree scan of three test fixtures;
  • test_multirepo_change_sets, test_policy_approval_is_narrow and test_toolchains_java;
  • test_every_template_runs_end_to_end and test_every_template_says_what_it_needs;
  • test_knowledge_code_parse and test_knowledge_code_graph_db;
  • test_release_planning_api, test_check_reports_unset_ability and test_a_catalogue_default_never_pins_its_agent;
  • the MCP parity audit and test_community_boss_cli's compose-services check;
  • the ones tests/known-failures.txt lists.
• No full suites were run. The autonomous agents have had no browser walk.

Known issues

• The Approve button on the deploy step's panel can fail step-up. Approve the deploy from the Approvals page instead.
• The planning panel can cut scope from a brief without saying so. Read the PRD before approving.
• A PRD has no "Request changes". You can only approve or reject it.
• Add repo lists only one GitHub account when several are connected.
• The GitHub App's return link can say "expired" after a successful install. The connection itself is made; reload Setup.
• Autonomous agents are a preview. They are off by default and have not had a browser walk.

Install and upgrade

Select v1.0-rc10.11 explicitly with the installer's --ref option, from a checkout of that same tag. See the Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). This release adds database tables for the autonomous agents; changing the checkout back does not undo database migrations.

BOSS Community v1.0-rc10.10

BOSS Community 1.0.0-rc.10.10 candidate

RC10.10 builds on rc10.9. It brings the knowledge graph (BOSSAPP-622), a new default database image, one agent pipeline for every place BOSS's agent chooses what to do (BOSSAPP-759), project creation, the Email (SMTP) connector, and the second round of alerting fixes.

This is a test candidate.

What changed

Knowledge graph

• A knowledge plane in BOSS's own database. It holds a code graph (Python, plus TypeScript, JavaScript, Go, Java and C# through tree-sitter) that resolves across files, and facts learned from builds. Pull requests, decisions and releases link to the symbols they touch.
• Retrieval fuses text, graph and vector results. An agent turn starts with a budgeted, quoted knowledge pack. A decision that cites facts shows "Based on".
• Each project has an AGE graph with read-only Cypher. Agents use the kg_* tools: kg_symbol, kg_callers, kg_blast_radius, kg_why, kg_search, kg_precedent and kg_propose_fact.
• Every shipped agent can read knowledge. Builder and reviewer roles can also propose facts.
• The knowledge setting is on, keyword or off. keyword gives agents plain full-text matches only: no graph hops, no vectors, no learned facts and no precedent. A person's own console search stays full.
• A console explorer and settings, with a promotion queue.

New default database image

• Postgres 16 on Alpine, with pgvector and Apache AGE compiled in (boss-community-db:pg16.12-vector0.8.1-age1.6.0, built from db-image/Dockerfile).
• The upgrade is an image swap. The existing data volume opens unchanged, and the schema step creates the extensions. boss upgrade first takes the complete protected backup, then swaps the image.

One agent pipeline (BOSSAPP-759)

• Metatron and the console talk to the same BOSS agent through one agent_turn. A Metatron sentence no longer goes through its own keyword reader and model decision. The Metatron terminal and Ask BOSS share the general chat thread.

• The captain autopilot is retired. Its powers are now the BOSS agent's actions: watch, goals and set goal the agent may run. Drive, overwatch and theater are offered to a person, who presses them. The worker's always-on overwatch now only observes.

• Every entry point that chooses a BOSS action goes through the pipeline:

  • alert triage and flap tuning;
  • the incident verdict;
  • GitHub issue triage and inbox replies;
  • focused agents;
  • the workflow agent step's agent choice;
  • agent-to-agent talk;
  • step recovery.

  Receipts, budgets and outcomes are unchanged. An enforcing test keeps new entry points on it.

• Every shipped agent has the same base.

Projects

• Create a project: POST /v1/projects, the agent's create_project action (also from the Metatron terminal), and New project in the top bar's project menu. A new project is seeded the same way as the default one: budget policy, members, agents, skills, MCP servers, workflows and trackers.
• The build composer is now "New build". "New project" appears only in the project menu.

Email

• Email (SMTP) is a connector. Enter one connection URL (smtp:// or smtps://) or the separate fields. Send test shows the server's own reply. The key goes to the secret store and is shown only as "set".
• One mail transport for every sender. Invites are branded, with a delivery status, the real reason for a failure, Resend and Copy link.
• Mailpit, the local test inbox, is opt-in: --with-mailpit or BOSS_EMAIL_DEV_INBOX=1. It is off by default.

Alerting, round 2

• A change never silently drops an app's monitoring. A pull request puts back alert and dashboard entries that the change removed without naming them. A deploy whose manifest lost rules keeps those rules running, and raises one alert until they are back. The Rules list marks a rule the latest manifest dropped.
• Tune a rule where it lives, from the Rules list.
• A settle window after a verified fix. A lagging alert inside the firing rule's own window joins the fixed occurrence as evidence and does not reset the incident.
• Grafana links work out the browser address themselves.
• The time label on logs uses one clock.
• rc10.9's BOSSAPP-602/603/604 items are fixed:
  • the release-commits check credits a run's own later steps;
  • runbook file names are stable;
  • the pack never ships over a broken test suite;
  • investigate() reads only the current occurrence;
  • a model out of credit says so and names the provider.

Setup and safety

• The boss-1 API-key fixes. Add a model drops stale pills and says why Connect is disabled. "Paused · budget" names the cap that is actually binding. A stale legacy exposure hold no longer blocks paid work forever.
• A refused write says its real reason. This covers setup, observability and connection-proof refusals, and the invite page's password hint.
• The installer ships the full commit SHA, and an ambiguous one is resolved or refused at backup time.
• The navigation no longer flashes the org picker mid-session.
• The web console type-checks against this tree's own API client.

Validation

• Targeted tests on the combined branch, for every change above. The operator chose targeted tests only. They covered:
  • knowledge, on the new database image;
  • email;
  • alerting round 2;
  • project creation;
  • the one agent pipeline and Metatron;
  • the installer and the image swap;
  • the identity route matrix and MCP parity;
  • web tsc and the touched web tests;
  • the P0 public-tree check.
• The plumbing e2e gate (scripts/e2e-gate.sh plumbing, no model calls) passed 19 of 19 checks.
• The real-agent release gate was not run for this candidate. It needs the operator's spend approval.
• No full suites were run.

Known issues

• BOSSAPP-760: the GitHub App callback can answer "unauthenticated".
• Metatron's client times out on long turns, and a turn can be refused with "budget admission busy" (both found 2026-10-23).
• The agent's tools can't target another project. A project the agent creates is set up, but follow-up actions still act on the current project.
• Knowledge graph ship gate is open (case_study_primary_not_run). These have not been run:
  • the case-study primary criteria;
  • the 1M-node AGE benchmark;
  • model precision;
  • retrieval at the 10M-node scale target.
• BOSSAPP-759 follow-ups: the captain's overwatch playbook stays deterministic inside its tools by design. Any further entry point that chooses a BOSS action must join the pipeline; the enforcing test lists them.

Install and upgrade

Select v1.0-rc10.10 explicitly with the installer's --ref option, from a checkout of that same tag. See the Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). The database image swap happens after that backup. Changing the checkout back does not undo database migrations.

BOSS Community v1.0-rc10.9

BOSS Community 1.0.0-rc.10.9 candidate

RC10.9 builds on rc10.8 and brings monitoring, alerting and agent-driven operations (BOSSAPP-598). It was exercised end to end in the "BOSS operations" demo:

• BOSS's SRE agent wrote an app's monitoring before release;
• a faulty release fired the alerts;
• the agent's own rule caught the bug and the agent opened the incident;
• Incident Response started by itself.

This is a test candidate.

What changed

Monitoring and alerting

• Connect any app. The Connect an app sheet:
  • Ways to send data: BOSS-built apps, OpenTelemetry (OTLP), Prometheus remote write, a /metrics URL, synthetic checks and heartbeats.
  • Alerts from other tools: Alertmanager, Grafana, Sentry, Datadog and CloudWatch, each with its own signed, rate-limited source token.
  • Confirmation: each path ends with a live check that data arrived.
• Rules in PromQL, in the Prometheus alerting-rule shape, checked against promtool.
  • Every rule shows its query, how often it runs, its window, For, Keep firing, threshold, severity and routing.
  • New alert rule builds a rule from an app's real metrics, writes the PromQL, and previews "would it have fired in the last 24 h".
• Severity SEV1–SEV4, with icons, and status chips: Firing, Acknowledged (by whom), Pending, Resolved (with duration), Silenced. The Alerts page leads with Needs attention.
• Alert lifecycle: pending, firing, keep-firing, flapping, no data and resolved; absence and heartbeat rules.
• Noise control: fingerprint dedupe, grouping by runbook, inhibition, silences, recurring maintenance windows, deploy holds and storm mode.
• Notification:
  • contact points (email with a signed ack link, Slack or Mattermost, signed webhooks);
  • an Alertmanager-style routing tree with a preview;
  • one message per incident, urgency and quiet hours;
  • a watchdog for the pipeline itself.
• A bundled Prometheus and Grafana in the install, receiving the apps' series. Each app gets a provisioned dashboard. Grafana and Explore links appear only when Grafana answers.
• The old reliability alert webhook now needs a per-source token.

Agents in operations

• Set up monitoring: a new workflow step before the release (in 14 workflows). The SRE agent reads the app's code and the metrics from the first deploy. It proposes a pack: SEV-rated rules, a runbook per rule and dashboard panels. It previews them on real traffic and retunes noisy ones, then writes them as code into boss.deploy.yaml in the same PR. The person approves the pack with the release; a monitoring_gate set to block stops a release with no pack.
• Agent triage names the agent and its reasoning on every alert.
  • When the agent isn't sure, it asks: the question shows as buttons, and a person's click goes through the same path as the agent's own decision.
  • Asking never holds back a notification.
• Respond automatically is per rule.
• The incident card shows who did what: triage, the investigating agent with its runbook, evidence and root cause, the fix crew and reviewers, the person's approval, deploy, verification and the report.
• A new release's failure opens its own incident instead of joining an old, unrelated one.

Safety

• A release card lists every commit it ships beyond the serving one, with each commit's run, that run's approval status and whether it was reviewed.
  • Commits from rejected or unreviewed runs need a written reason.
  • An approval binds to the list it was shown.
  • The deploy ships exactly the approved head.
• Incident fixes are built on their own branch, cut from the serving commit.
• A promised spec approval holds the build. Approving a PRD whose workflow already builds never starts a second build.
• The Jev router hold (from main, PR #10, BOSSAPP-579).

Validation

• Targeted tests for every change above (the operator chose targeted tests only).
• The "BOSS operations" demo, run live on the laptop install. It stopped at an incident fix build when the model account ran out of credit.
• No full suites and no real-agent release gate were run for this candidate. There was no model credit, and the operator chose targeted tests only.

Known issues

• BOSSAPP-602:
  • The release-commits check doesn't credit a run's own More-tests and Set-up-monitoring commits.
  • Set up monitoring writes duplicate runbooks on retry, and its pack can break an app's own manifest test.
  • investigate() reads older occurrences on a reused incident.
  • A time label is wrong, and there are other console nits.
• A model running out of credit is shown as "no model is answering".
• Plumbing: the bundled Prometheus's remote-write forwarding is untested against load, and the 5,000-rule benchmark was not run (BOSSAPP-599).

Install and upgrade

Select v1.0-rc10.9 explicitly with the installer's --ref option, from a checkout of that same tag. See the Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). Changing the checkout back does not undo database migrations.

BOSS Community v1.0-rc10.8

BOSS Community 1.0.0-rc.10.8 candidate

RC10.8 builds on rc10.7. It came from the D2 demo:

• BOSS built an Order API and deployed it next to HelpDesk AI;
• a faulty release went out and customers complained in HelpDesk;
• BOSS's own alert fired, and BOSS investigated, fixed, verified recovery and posted the root cause back to the customers' tickets.

That run was driven through BOSS's own agents. This is a test candidate.

What changed

Agents decide by reasoning, never by keywords

• Every agent decision goes through one model-decided step.
  • What the model is given: the request, the conversation, the record in view, a project glance and the candidate actions. Each action says whether it is available, and if not, where it is done.
  • Who decides: the decision model (Jev, when it is not held), otherwise the project's model.
  • When unsure: below the confidence threshold the agent asks one question instead of acting. With no model connected, it says so and does nothing.
  • Keywords are hints only. Keywords and coded triage reach the model as hints. They no longer pick an action anywhere: the chat router, step recovery, inbox replies, the terminal or issue triage.
• The agent battle test (scripts/agent-battle-test.sh): 18 scenarios from real mistakes, 164 phrasings including negative controls. They run against the real agents with every write intercepted, and are graded by a separate model. The score went from 63% to 94%.

BOSS fixes itself

• When a recovery agent decides a failure is BOSS's own bug, Mender, BOSS's maintainer agent:
  • re-diagnoses the bug against the code;
  • writes a test that fails on the current code;
  • writes the smallest fix that passes it.
• The fix must pass every mechanical gate: protected paths and gate code, tests never weakened, the test driving the real entry point, BOSS's affected suites and its P0 tier. Four reviewers then check it, with the security reviewer on a second engine where one is configured.
• A person approves every install. A host self-installer runs only signed, single-use tickets and keeps the previous build. The stuck step resumes and verifies the fix. The same failure coming back rolls it back automatically.
• Local fixes survive upgrades, and are dropped once the release contains them.
• Send to BOSS team sends exactly what was previewed, redacted, de-duplicated, and labelled source:boss-agent.
• Verified with a real model end to end on a replay of a real deploy bug: diagnosed, test then fix, every gate and all four reviewers passed, approved, installed, the step resumed, verified. That attempt cost $4.56.

Incidents for any app BOSS deploys

• An app's error-rate alert records the release it fired on. An app can also report a suspected incident through a signed per-app channel (signals: in boss.deploy.yaml), which opens or joins one incident but can never start a code change.
• The Incident Response workflow:
  1. investigates the failing route, the app's logs and the release diff;
  2. builds the fix as the app's next change, with a regression test;
  3. waits for CI;
  4. asks a person to approve the release;
  5. deploys;
  6. verifies recovery from BOSS's own monitoring;
  7. writes a report with the timeline and cost;
  8. posts the root cause back to the reporting app.
• Respond automatically on an incident acts under the person's scoped grant.

App alerts (v1)

• Every app has an Alerts tab in Observability, and there is an all-apps Alerts page. Factory's ⋯ › Alerts opens it.
• Rules are written in PromQL in the Prometheus alerting-rule shape, and promtool proves they mean the same thing to BOSS and to Prometheus. There are five built-ins (error rate, p95 latency, health check, deploy unhealthy, and no traffic, which is off by default). An app's alerts: key in boss.deploy.yaml can add its own rules.
• A fired alert shows its query, the value at breach, a Grafana Explore link, the runbook, and the agent's triage in its own words.
• Noise control, Alertmanager-style:
  • a re-firing alert is the same alert (fingerprint dedupe);
  • breaches that share a runbook become one incident;
  • health and deploy alerts hold back the symptom alerts they cause;
  • silences need a reason and are audited.
• Respond automatically is per rule, never per app. The incident card's app-wide switch is retired. Its setting moves to the matching rules, under the same person's grant, and the move is audited.
• Grafana links appear only after BOSS has checked that Grafana answers. Otherwise the screen says why, and offers Check and Deploy stack.

Safety

• A deploy that promises a person's approval always asks for it, whatever the environment policy allows. The wording on every screen and the runtime come from one source.

Fixes from the run

• GitHub:
  • pushes use the connected GitHub App's one-repository token, which carries workflows: write while the repository has opted in;
  • CI is read with the same token.
• Deploys and Infra:
  • Infra's Deploy plans a stack deploy from the target's manifest;
  • an incident's evidence and steps always read in one order.
• Setup: shows the demo password the deploy actually runs with.
• Talk to BOSS:
  • asks for consent instead of showing a raw 409;
  • never claims an action it did not take;
  • carries out a retry on the existing work instead of starting new work.

Validation

• Release gate, plumbing: PASS, 19 of 19 checks in 57 s.
• Release gate, real agent: PASS on the build itself. It first ran in 17.6 min, but one check failed because the build profile was recorded 10 min late (fixed here). A re-run built successfully in 25.2 min after two review rounds, 12 s over the 25 min budget, and was not re-run again to save credits.
• Targeted tests for the last fixes and App alerts: 60 passed.
• P0 tier: engine 489, API 122, web 148, all passed.
• P1 tier: engine 531 and web 689 passed. API: 139 passed, with 2 Postgres shared-memory errors in the sharded run that pass when re-run alone.
• The D2 run itself, recorded end to end.
• Fixed before release: a build's profile is now recorded the moment the run finishes, and a preview never holds the build (a 404 fails in about 15 s, not 10 min).

Known issues

• The release-approval card doesn't yet show the PR, the CI result or the root cause.
• A fix PR may carry the preview harness's root package.json changes.
• Alerting: notifications (email, Slack, webhook), connecting apps BOSS didn't build, SLOs and rollback-first response are the next candidate (BOSSAPP-598 Phase 1).
• The battle test has been run on one engine (Claude Code) so far. A Roll back after a removal is the weakest scenario (6 of 9).

Install and upgrade

Select v1.0-rc10.8 explicitly with the installer's --ref option, from a checkout of that same tag. See the Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). Changing the checkout back does not undo database migrations.

BOSS Community v1.0-rc10.7

BOSS Community 1.0.0-rc.10.7 candidate

RC10.7 builds on rc10.6. Everything in it came from a second full HelpDesk AI run, recorded end to end:

• the app built from a brief and deployed;
• a second feature (ticket tags) added onto the live app;
• a third (a new look with a dashboard and dark mode) built and deployed on top.

Each failure on that run was fixed in BOSS as a class, with tests. This is a test candidate.

What changed

Agents recover first

• A failed step goes to its own agent before a person. The step's recovery agent reads the failure and the machine, then acts within a budget: retry, fix the app, clean up and retry, wait for a BOSS update, or ask a person one question. It never repeats an action that already failed. A cause in BOSS itself is recorded as a recommendation for BOSS's developers, and the step resumes by itself once BOSS is updated.
• Open review findings go to the agent too. A build stopped on findings it could not fix is handed to its recovery agent with the findings word for word, before anyone is asked to waive a check.
• A step follows the Retry a person pressed. It no longer keeps waiting on the attempt that was replaced.

A pull request opens even when checks fail

• New project setting, "Open the PR when checks fail" (on by default). After its repair rounds, a build whose checks still fail opens its pull request instead of stopping for a waiver:
  • the PR opens as a draft with the label checks failing;
  • its body lists every failing check and finding, security first;
  • a follow-up task is started to fix them;
  • the run carries on to the merge decision.
• The merge card leads with the failing checks. A plain Approve is refused. "Merge with checks failing" needs a written reason and is recorded.
• "Merged" means merged. A pull request is shown as merged only when it really was, either from GitHub's state or from a recorded merge commit. An approval with no merge behind it reads "Approved · not merged". A deploy of an unmerged PR says so.

Deploys

• A new release retires the app's earlier release from the database's shared project before it starts, so the old container no longer holds the port. Only containers started from the app's own folder are removed, never the database or another app's.
• A release that brings its own database is not handed the old one. The address BOSS's database was bound to for an earlier release no longer reaches a release that runs its own.
• Roll back works for a release deployed from a declared manifest.
• Roll back and Redeploy never replay a removal. Before this, a Roll back could re-run an earlier governed removal, including deleting its data, without a new approval. A removal is now only ever its own act, with the typed app name and its own approval.
• Remove app stops the containers that are actually running, including the shared project. In Deploys a removal reads Removed, never Live, and Remove app… is reachable from any deploy's menu.

Builds

• Every new change to an app plans itself. Before this, a follow-up build reused the previous build's plan: a "new look" build re-implemented the previous feature. The earlier plan is now reference only.
• BOSS's own description of the deploy machine is no longer read as the brief asking for Java, Ruby or PHP.
• A next attempt is never merged into the attempt it replaces.

Console

• A single-page app previews at its own paths. A React Router app no longer renders blank under the preview address, and a reload comes back to the preview.
• App Setup:
  • the "Set up sign-in" chip sits under the app name instead of hiding it;
  • the BOSS sign-in row gives a reason and a Try again button instead of "Failed to fetch";
  • an approval-seat refusal tells apart two people with the same name.
• The full console test suite passes: 7,367 tests.

Validation

• Release gate, plumbing: 19 of 19 checks in 57 s.
• Release gate, real agent: a full build (Onboarding Path Builder) finished in 12.3 min against a 25 min budget and opened its PR.
• Full suites: engine, API and console (results in the release description).
• The HelpDesk AI run on this branch: brief, PRD, architecture, build, PR, deploy, monitoring, then two features added onto the live app and deployed.

Known issues

• A manual Deploy from the Infra drawer of an SSH target can take the old single-container path and fail at transfer. Workflow deploys are not affected.
• On a Community install the release gate's test-account step needs the seed module copied in. Its printed hint names a command that the install's image does not include. This will be fixed.
• Recovery agents diagnose BOSS-side causes but cannot yet change BOSS's code. That is the headline of the next candidate, "BOSS fixes itself".

Install and upgrade

Select v1.0-rc10.7 explicitly with the installer's --ref option, from a checkout of that same tag. See the Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). Changing the checkout back does not undo database migrations.

Validation results for this tag

• e2e gate, plumbing: PASS, 19/19 checks in 57 s.
• e2e gate, real agent: PASS, Onboarding Path Builder in 12.3 min (budget 25), with its PR opened and cleaned up.
• P1 tier: engine 438 passed, console 631 passed, API 133 passed. 3 API tests hit Postgres out of shared memory while 6 shards ran at once, and all 3 pass on a re-run.
• Full console suite: 7,367 passed.
• Private-infrastructure P0: passes, and no private server address appears in the release history.

Commit: 852e33593. Upgrade with ./scripts/install/upgrade.sh --dir <your-install> --ref v1.0-rc10.7.

BOSS v1.0-rc10.6

BOSS Community 1.0.0-rc.10.6 candidate

RC10.6 builds on rc10.5. It is the first candidate with a complete HelpDesk AI run behind it: brief, PRD,
architecture, build, PR, preview, more tests, deploy, monitoring and notify, ending with a working app
on a deploy host. Everything that run needed is in this release. This is a test candidate.

What changed

Deploys that fix themselves

• The host is asked first. Before anything is touched, the deploy checks the machine for every program
  the manifest runs and records what it has (Docker, Node, Python…). A manifest that runs npm on a machine
  without Node is refused with that reason, not after the release was half switched.
• Fix and redeploy. When a deploy fails for the app's own reason, BOSS starts a repair build on the same
  PR branch with the failure, the log and the machine's facts, then redeploys the new commit. A failure on the
  machine's side (SSH, disk, Docker) still goes to a person, and so does a deployment someone rejected.
• The build knows the target. A build that will be deployed is told what the target machine has, so it
  writes the right manifest the first time.
• Compose apps reach their database. A kind: compose app runs in the same project as the resources BOSS
  provisioned for it, so res-db resolves; an older copy of the app under its own project is retired first so
  it cannot hold the port. A failed health check now records the containers' state and the app's own last
  lines.
• An app name with a space can hold a provisioned secret.

Runs that finish

• A team nobody chose gains the workflow's agents, including approvers inside parallel branches, so a deploy
  is not refused for "release_manager is not assigned".
• A failed run keeps its authority for 24 hours, so retrying a step can finish the run.
• A retry builds onto the kept work, never an empty tree, and the secret scan gives the builder one turn to
  fix a finding before blocking.
• The app's folder comes from the app's record. In a repository with several apps, a planner never treats
  the shared root as the app; with no evidence it refuses instead of guessing.
• An app start keeps its own output and gets the environment the app declares.

Console

• App Setup redesigned. One card per connector (earlier attempts folded), a collapsible row per sign-in
  provider with its steps, callback and keys, warnings only where an address cannot work, and a Settings tab
  that separates what BOSS manages from your own settings. The Factory row shows a "Set up sign-in" chip when
  something needs you.
• One Retry on screen. Retry opens a single panel with an optional note whose example fits the step.
• An app's health panel opens wide and expands to the whole page.

Not yet verified

• Agents recovering on their own across builds and deploys (being built for the next candidate).
• The live per-engine matrix (Codex, OpenRouter, Groq, Ollama) on the release gate.
• Website installer parity.

Install and upgrade

Select v1.0-rc10.6 explicitly with the installer's --ref option, from a checkout of that same tag. See the
Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). Changing
the checkout back does not undo database migrations.

BOSS v1.0-rc10.5

BOSS Community 1.0.0-rc.10.5 candidate

RC10.5 builds on the published rc10.4 candidate. It carries the work prepared on the rc10.5 and rc10.6 branches, which was merged but never tagged, and everything merged since. The candidates rc10 to rc10.4 left the package version at rc9 and the install guides at rc8; both now name this release. This is a test candidate. The automated suites pass on the release commit; the live checks listed under Not yet verified have not been run.

What changed

Engines and agents

• One contract for every engine. Claude Code, Codex, the Claude Agent SDK and BOSS's own agent run the same pipeline, gates, fix rounds and failure messages. Where an engine lacks a feature (session resume, a read-only flag), BOSS supplies it. See Engine contract.
• A conformance gate with no model. e2e-gate.sh engines runs the real pipeline on a scripted engine and checks every gate on the poorest and the richest profile.
• Every agent knows BOSS's fundamentals. Every role, including new and custom ones, holds read access to logs, code and run history. It can query its own project's data read-only and propose a fix for a person to approve.
• An agent session never holds the model API key. Calls go through a loopback proxy, which records their usage.
• Claude Agent SDK engine. Builds, reviews and agents can run on an Anthropic API key, selected per job or for the whole install.

Building apps

• Java apps. Maven and Gradle projects (Spring Boot, JAX-RS) preview in a container, deploy over SSH and are pre-checked. See Toolchains.
• Native packages compile. The build image carries a C/C++ toolchain, so packages like better-sqlite3 and bcrypt install.
• Several connectors in one build. For example Login, Payments and Email together on one app, integrated in the app's own look.
• New email connector. SMTP or Resend, with a local mail catcher for previews.
• Faster builds. Writing stages run in parallel sessions sized from the host (Setup › Build speed). A long model stretch reports progress every 30 seconds. Every build logs where its time and tokens went.
• A More tests pass on every code-building workflow. It follows the preview on the same PR and never blocks the build.

Workflows

• New step types and controls. For each runs one step per item of a list. A signed webhook can start a workflow. A step can back off, time out and take an error path.
• Test runs. A test run uses pinned data, and you can run again from a step.
• Designer blocks. The designer places Branch, Parallel/Join, Repeat-until and For each blocks, with arrows you can drag.
• One approval per deploy. The environment's policy decides whether to ask.
• Remove a deployed app, governed like a deploy. Data is kept unless you ask otherwise.

Reliability

• Startup no longer locks the whole database. The schema apply commits each statement, and the column check only alters missing columns. Before, writes running during startup could deadlock against it.
• Retries use the database's clock. A retry is scheduled on the same clock that decides whether it is due.
• Expired holds wait for a person. The pre-check reports a positive-amount expired hold for a person to reconcile in Decisions, instead of fixing it automatically.
• The org board only changes when something happens. It no longer reports a change every second while an agent is working.
• The heartbeat carries the version again, including point releases like this one.
• The installer picks the newest candidate by number. It compared release names as text, so a fresh install asking for the newest candidate got rc9 instead of rc10.x.
• Releasing a held proof from the CLI checks your identity permissions when identity enforcement is on.

Not yet verified

These need a laptop or real model keys and have not been run for this candidate:

• A real image build of Dockerfile.community with a native npm package installed inside it.
• The live per-engine matrix: Claude Code, Codex, OpenRouter, Groq and Ollama on the release gate.
• An agent diagnosing a real failed build from its logs, code and data with a live model.
• The full HelpDesk AI run: brief, build, PR, deploy and a working app.
• Website installer parity. The hosted installer is updated separately from source releases.

Install and upgrade

Select v1.0-rc10.5 explicitly with the installer's --ref option, from a checkout of that same tag. See the Quickstart.

Before upgrading an existing install, take a complete protected backup (boss upgrade does this). Changing the checkout back does not undo database migrations.

BOSS v1.0-rc10.4

BOSS v1.0-rc10.4 fixes why a finished HelpDesk build couldn't start its app, and makes BOSS ride out GitHub's bad moments without redoing work.

Commit: f9f4c23a on main (fast-forward from 41549288).

Highlights

Programs a build installs stay runnable

• Builds install as the run's own user with a restricted umask. BOSS's "make everything a run made readable" pass added read and write for others but never execute, so node_modules/.bin/tsx became readable but not runnable by the user starting the app. The HelpDesk build failed its app-start check with tsx: Permission denied after its tests had passed.
• One rule now applies wherever BOSS copies or opens a workspace: read and write for everyone, and execute for everyone when anyone had it. It never removes a bit. That covers the app-start proof, previews, the security scan and the toolchain cache (a Gradle wrapper lost its execute bit the same way).
• A blocked build names the check that actually failed: "Blocked: the app did not start: tsx: Permission denied", not "the template's tests did not pass".

GitHub errors are retried in place

• Clone, fetch, push and GitHub API calls retry 3 times (10 s, then 30 s) on HTTP 5xx, "RPC failed", "early EOF", "expected 'packfile'", and connection resets or timeouts. Sign-in and permission answers (401/403/404) are never retried. Each retry is logged on the build.

Retry only the step that failed

• If the push or PR still fails after a finished, checked build, the build, its tests and its review are kept. Retry pushes and opens the PR only.
• A retry of an attempt that built nothing is a fresh build of the brief, in the app's own folder. Before, it was treated as a repair at the repo root and took other apps' tests as its suite.
• The test budget counts only tests this build wrote inside its app's folder, and never touches other tests.

BOSS's own retries act only for the person who started the build

• An automatic retry carries the consent the person gave that build, scoped to the same run and never widened. If there's none, BOSS doesn't start one and leaves Retry for a person. A build that failed before BOSS restarted is never retried on its own.
• Root cause of the refused "· retry 1" builds: the retry was started from the worker's own key, so the person's consent wasn't carried.

Validation

• Release gate: P0 + P1 (scripts/test-tier.sh major): no new failures. Web 772 passed. Engine and API failures all match tests/known-failures.txt. An earlier gate run hit a setup error in one API test when shards ran in parallel; run on its own, that file passes 17/17, twice.
• New tests: 81 passing, including:
  • test_an_installed_executable_stays_executable.py (21, including a real npm install under umask 007)
  • test_a_github_blip_is_retried_in_place.py
  • test_an_automatic_retry_runs_under_the_persons_grant_or_not_at_all.py
  • test_a_retry_of_nothing_is_a_fresh_build_of_its_own_app.py
  • test_a_failed_delivery_retries_only_the_delivery.py

Known issues

• The next HelpDesk AI run is the live proof.
• One connector per build.
• After a 6-digit step-up, an approval isn't re-sent; press Approve again.
• A gate step just approved can show "needs a person" until the page refreshes.

Upgrade

./scripts/install/upgrade.sh --ref v1.0-rc10.4