Rapid OS 3.2.0rc3

[3.2.0rc3] - 2026-11-09 (pre-release)

Third release candidate for 3.2.0 (git tag v3.2.0-rc.3, PEP 440 version 3.2.0rc3). The latest stable release is still v3.1.1: the README and the installation docs keep documenting it until the final 3.2.0 release, while the installers pin this tag. If you tried rc2, this is what changes:

• Data access per stack. Onboarding has a new step, choose_data_access: each backend stack names one ORM, query builder, driver or ODM, and tech-stack.md and the data-model action carry it.
• Hono and Cloudflare. New stack hono (Cloudflare Workers) and deployment template cloudflare, with compatibility notes when a data access option or a service has no equivalent in Workers.
• Line endings on Windows. rapid setup finish and rapid init write .rapid-os/** -text to .gitattributes, so core.autocrlf no longer breaks the evidence when you clone on Windows. rapid doctor warns with RAPID1436 when the rule is missing.
• Unconfirmed drafts. rapid start and rapid next remind you of onboarding documents that are still drafts, with the command that confirms them.
• Research runs. rapid task done in a research run no longer runs the test command; the task closes as UNVERIFIED.

Upgrading from rc2

• In a project that already has .rapid-os/ in commits, run rapid setup finish to add the rule to .gitattributes. A .rapid-os/** -text line you added by hand also counts.
• Then, in the copy where rapid evidence verify passes, run git add --renormalize .rapid-os/ and commit. Do not renormalize in a clone that already fails: bring .rapid-os/ from the good copy. rapid doctor warns with RAPID1436 until the rule is there.

Known issues

• Outside Claude Code there are no hooks, so nothing stops an agent with a shell from writing to .rapid-os/ directly. In Claude Code the hooks block it on a best-effort basis.
• Evidence is not signed: records written directly under .rapid-os/ can look valid.
• Research during onboarding arrives in 3.3 (H-37).

Detailed changes

Added

• Data access per stack: every backend stack declares data_access (ORM, query builder, driver or ODM, with engines, runtimes, migration commands or schema validation, notes and official sources). New onboarding step choose_data_access, rapid setup set data-access <id> [--component backend] and --recommended; a single compatible option is fixed and reported. It is stored in setup.json as an optional field. tech-stack.md names the option chosen and the data-model action carries its commands.
• Stack hono: Hono on Cloudflare Workers, with PostgreSQL and MySQL through Hyperdrive. rapid setup set services rejects RabbitMQ, Kafka and other engines it cannot use, naming the platform's alternative. The scanner suggests it from the hono dependency.
• Deployment template cloudflare (rapid deploy --target cloudflare). The scanner detects wrangler.json and wrangler.jsonc as well as wrangler.toml. The deployment action carries platform_notes.cloudflare when the backend's data access option (the recommended one if none was chosen) or a decided service (@now or @later) has no equivalent in Workers, with the platform's alternative and without blocking. One map in rapid_os/domain/data_access.py gives those alternatives, and a test checks that hono.json and the Cloudflare template say the same.

Changed

• The stack templates name one data access option instead of several (Prisma / Drizzle, TypeORM / Prisma / Drizzle, Spring Data JPA / JDBC). hosting_fit accepts edge. gate.architecture also forbids drizzle-orm and kysely in the domain layer of node-fastify and node-nestjs.

Fixed

• The live smoke test of docs-deploy.yml looked for the Spanish heading at the English route /tutorials, so every deployment ended in failure after publishing the site. It now checks each language at its own route, and a test without network access compares those headings with their source pages.
• The README no longer says that main is at 3.2.0.dev0.
• With core.autocrlf=true (the default of Git for Windows) git changed the line endings of evidence artifacts when adding and when checking out, and rapid evidence verify, rapid eval show and rapid validate failed in a clone with RAPID1205 and RAPID1223. rapid setup finish and rapid init now write .rapid-os/** -text to .gitattributes (a managed block between RAPID-OS:BEGIN and RAPID-OS:END; the rest of the file is not touched), rapid doctor warns when the rule is missing (RAPID1436), and a failed comparison of a text artifact names the probable cause and the repair (RAPID1437). Verification stays strict: a converted file is still rejected. A .rapid-os/** -text line the person added by hand outside the managed block counts as the rule, and the block is not added again.
• rapid doctor gave RAPID1321 in every project because it compared all the harnesses Rapid OS knows. It now compares the agents chosen in the project; without a configured project it does not warn.
• Updating Rapid OS made rapid validate --strict fail with RAPID1403 on documents confirmed before a section was required. For a document confirmed with an earlier set of required sections the diagnostic is now informational and points to rapid setup doc <id> --reopen. setup.json records that set (confirmed_bank) at each confirmation, and a document without it counts as earlier; one confirmed with the current sections keeps the warning.
• rapid task done T00N without --no-check ran the test command in a research run and exited 2 when there was no code yet. In that mode it now behaves as with --no-check (same record, UNVERIFIED) and says so in one line; rapid check evidence of the task counts as usual. Other modes do not change.
• /rapid-init let an agent take the agents, the archetype and the topology from its memory of other projects without asking. The shortcut now says that agents, archetype, topology, AI and test command are the person's decisions in each project: a remembered preference can only be offered as a recommendation that names its origin, a choice different from the catalog's is said and asked, and rapid setup set test-command --recommended comes first for the test command.
• The review of the drafts promised that each run would remind the person of an unconfirmed document, but RAPID1408 only appeared in validate and doctor. The action of rapid start and rapid next now carries unconfirmed_docs (id and file) while there are drafts, the text output says so in one line with rapid setup doc <id> --confirm, and the work shortcuts tell the agent to mention it once and ask before implementing anything that depends on those assumptions, without treating them as rules or confirming them. The text of the review describes exactly this.
• rapid eval show, rapid evidence list and rapid evidence verify without --run failed with an argparse error. They now use the active run or, if there is none, the last one closed, and the text output starts with Run: <id>; without runs they fail with a clear error (RAPID1221 or RAPID1202).
• Rewriting a draft with rapid setup doc <id> --source drafted --replace left docs/<file>.<ts>.bak beside the document, and it reached the first commit. When the previous file is an agent's draft, its copy now goes to .rapid-os/backups/ (the last 5); only content from a person keeps its copy beside the document.
• rapid check -- <experiment> --task T00N in a research run warned that it could not read a test count, which does not apply to a spike: the exception for research read a mode the execution contract does not have. The mode now comes from the run's spec revision.

---

Rapid OS 3.2.0rc2

Second release candidate for 3.2.0 (git tag v3.2.0-rc.2, PEP 440 version 3.2.0rc2). The latest stable release is still v3.1.1: the README and the installation docs keep documenting it until the final 3.2.0 release, while the installers pin this tag. If you tried rc1, this is what changes:

• Evidence integrity (ruleset 3). In new runs, PASS needs real tests run by rapid check and a human approval made with rapid approve; plumbing no longer satisfies those gates.
• Windows. Text sent through stdin is read as UTF-8 whatever the console code page, rapid check finds .cmd executables, Git calls in worktrees handle long paths, and a smoke job checks a real wheel on Windows in CI.
• Runs with a worktree. rapid finish reports the real paths and safe commands when the worktree is dirty, and rapid finish --merge commits and merges after the person's written confirmation.
• Hardening findings. Rapid OS calculates the score from the CVSS v4.0 vector, and the declared severity must match it.
• BaaS providers. fullstack-baas decides Supabase or Firebase like any other stack.
• /rapid-research. It says how to research and where to save the findings with their sources, and rapid attach is pre-approved in that mode.
• Specs from rc1. Specs written with rc1 or 3.1 still read and validate; you do not need to rewrite them.

Known issues

• Outside Claude Code there are no hooks, so nothing stops an agent with a shell from writing to .rapid-os/ directly. In Claude Code the hooks block it on a best-effort basis.
• Evidence is not signed: records written directly under .rapid-os/ can look valid.
• Research during onboarding arrives in 3.3 (H-37).

Detailed changes

Changed

• README: the hero states what Rapid OS does (the agent says it is done, and Rapid OS checks that with evidence it runs itself and with your approval), the shortcuts come first, and a new table says what each harness guarantees and what it does not.
• Packaging: the license uses the SPDX form (license = "MIT", license-files = ["LICENSE"], PEP 639), which needs setuptools>=77.0.3 to build; the license classifier is gone because PEP 639 does not allow both.

Added

• Community files: SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md (Contributor Covenant 2.1), issue forms and a pull request template.
• CI: a Windows smoke job (windows-smoke.yml, scripts/windows_smoke.py) builds the wheel, installs it in a clean venv and checks rapid --version, a minimal onboarding, a spec with accents through a pipe (H-29), rapid check with a .cmd executable (H-32) and the regression tests of those fixes.

Security

• Every uses: in the workflows and in the CI example of the docs is pinned to the full commit SHA of a published tag, with a # vX.Y.Z comment (the same commit the moving tag pointed to), and .github/dependabot.yml keeps the pins current. A test refuses a uses: without a 40-character SHA.
• Evidence integrity, ruleset 3 (external 3.2 audit, R1–R5 and P1-3). Before, a run could reach PASS without real tests and without a real human approval. New runs record ruleset_version: 3 in their contract and are evaluated with it; reports saved with ruleset 1 or 2 still replay with their own rules, and runs created before keep ruleset 2.
  • Test gates (gate.tests, gate.baseline) only count evidence produced by rapid:check whose output had a counted test summary (counted, now in the payload) or whose argv is exactly test_command (test_command), with at least one test executed and a recorded tree; anything else leaves the gate unverified. rapid check --kind test on a command without a summary records a command_result and says so (RAPID1432), and rapid next returns verify with the reason instead of asking for approval.
  • rapid evidence add refuses the producers reserved to Rapid OS (rapid:*), a review from user, and the review fields via, tree and accepts (RAPID1430); the ledger still reads them.
  • rapid run gate refuses human gates (RAPID1431): only rapid approve <gate>, in the person's terminal, moves them; in ruleset 3 a human gate only counts with a review written by rapid approve (via: rapid:approve).
  • rapid approve records the approved working tree; rapid finish refuses code that changed after the approval and names the files (RAPID1433), and rapid approve can approve the gate again on the new code.
  • Fail closed: in a run of ruleset 3, test evidence without a readable tree counts as unverified code for rapid next, rapid approve and rapid finish (RAPID1434).
  • A test command other than the baseline's blocks rapid finish (RAPID1435) unless the person accepts it in their terminal with rapid finish --accept-test-command "REASON" (the same agent and TTY checks as rapid approve); the acceptance is recorded as evidence with the reason.
  • The manual walkthrough (docs/tutorials/first-governed-project.md, also in Spanish) now reaches PASS with the daily commands only (start, next, check, task, approve, finish); the plumbing (evidence add, run gate) moved to a reference section that says it does not satisfy test or human gates.
  • Out of scope: an agent with a shell can still write files under .rapid-os/ directly (in Claude Code the hooks block it); closing that fully needs a channel outside the agent's reach.

Fixed

• Mode templates: the feature spec template no longer suggests Rapid OS's own paths (rapid_os/orchestration/, Pruebas unitarias en tests/) to the user's project. /rapid-research asks for rapid check -- <comando> only when the experiment runs code.

• /rapid-research shortcut. Its loop and the Conductor ask for rapid attach, but the template did not list it in allowed-commands, so Claude Code asked for permission at the mode's central step; attach is now pre-approved for research only. The shortcut now says how to research: the harness's own web search and MCP servers (Rapid OS does not search), an experiment in the repo over an article's opinion, findings saved with their sources in experiments/<id-de-la-spec>/T00N.md before rapid attach --task T00N, the task closed with the action.after that already carries --no-check, and no invented sources. The five mode spec templates (templates/modes/*.json) no longer carry Rapid OS's own repo constraints ("Sin nuevas dependencias", "Python stdlib 3.10-3.13") into the user's project: one neutral constraint points to the project's tech stack instead. In research, affected_paths is experiments/<id-de-la-spec>/ and T002/T003 name the findings file.

• Specs written before hardening findings (3.1, 3.2.0rc1; H-38). revision.json without findings has a content digest computed without that key: SpecRevision.from_dict accepted it, but the spec registry and the run/spec binding compared the new digest, so rapid validate reported RAPID804 (and RAPID1003) for every such spec, and a hardening run with a report ended rapid validate with a traceback. One rule (SpecRevision.matches_content_digest) now serves all three: the current digest, or the legacy one for a revision stored without findings. The evaluation reads the spec revision the run is pinned to, and a spec that cannot be read is a diagnostic with its code in rapid validate and rapid eval, never a traceback.

• Windows (3.2.0rc1 e2e, H-29): specs and documents sent through stdin were read with the console code page (cp1252) and stored as válidas, Módulo, dueño, and a spec id came out ...notificacia3n-de. Text handed over as data (rapid start --spec-file - and <path>, rapid setup doc --file, rapid setup stack --custom --file) is now read as bytes and decoded as UTF-8 (a BOM is accepted), sys.stdin is reconfigured to UTF-8 when it is not a terminal, and text that is not UTF-8 is refused with RAPID1424 instead of being stored altered. rapid doctor warns with RAPID1425 about a saved spec or onboarding document that already holds UTF-8 read as cp1252 (saved specs are not rewritten: create a revision with rapid spec revise). read_text_best_effort no longer falls back to the platform encoding.

• Windows (H-32): rapid check resolves the executable with the PATH and PATHEXT before running it (pnpm, npm, yarn are .cmd shims that subprocess does not find without a shell); the argv compared with test_command and recorded stays as typed. The combined test command for two components resolves each executable the same way, runs them all and exits 1 if any exit code is not 0 (max() hid a process killed by a signal), uses a python/python3 that exists or this interpreter, and rapid setup next prints it quoted.

• rapid doctor and rapid start warn with RAPID1426 when test_command cannot be run, proposing the stack catalog's command with the new rapid setup set test-command --recommended (it lists each component's command and applies the combined one without typing it); rapid setup records the SHA-256 of the agent files it generates in .rapid-os/generated.json and warns with RAPID1427 before overwriting one that was edited by hand (the previous copy goes to .rapid-os/backups/; a change of line endings alone is not an edit, and generated.json is versioned with the project).

• Worktree closure: rapid finish reports the real paths and safe commit/merge/remove commands when a run worktree is dirty; --merge requires the person's written confirmation, commits on rapid/<run-id>, and merges into the source checkout. Windows worktree Git calls enable core.longpaths per command, and rapid doctor warns about long evidence paths.

• Run guidance and validation: pending approvals make rapid finish exit nonzero and rapid next lists each exact approval command; rapid check refuses terminal runs; invalid approval IDs l...

Rapid OS v3.1.1

Rapid OS v3.1.1 Release Notes

Release Version: 3.1.1
Artifact Schema Version: 1 (unchanged from 3.1.0)
Python Requirement: Python >=3.10 (3.10, 3.11, 3.12, and 3.13 verified in CI)

---

1. Overview

Rapid OS v3.1.1 is a patch release that makes the stable installers work with coding harnesses. Before this release, install.sh added a shell alias and install.ps1 added a PowerShell profile function. Shortcuts (/rapid-<mode>) and Claude Code hooks run rapid from the agent's own non-interactive shell (Git Bash on Windows), which sees neither aliases nor profile functions, so they failed with rapid: command not found.

No command, flag, JSON output or artifact changed. Everything documented in the v3.1.0 release notes still applies.

---

2. What changed

• install.sh (Linux, macOS, WSL): creates a private Python environment in ~/.rapid-os/.venv, installs Rapid OS in it (editable, so git checkout --detach <tag> in ~/.rapid-os keeps upgrading it) and links the executable to ~/.local/bin/rapid. If ~/.local/bin is not on PATH, it adds it to ~/.bashrc or ~/.zshrc. It removes the alias rapid= line written by earlier installers (backup *.rapid-os.bak). Debian/Ubuntu need the python3-venv package.
• install.ps1 (Windows): creates $HOME\.rapid-os\.venv, installs Rapid OS in it, copies rapid.exe to $HOME\.rapid-os\bin and adds that folder to the user PATH. Only rapid.exe lands on PATH, so the environment's python.exe never replaces yours. It removes the function rapid written by earlier installers to $PROFILE (backup *.rapid-os.bak).
• Documentation: the installation pages and the troubleshooting guide explain that shortcuts and hooks need rapid as an executable on PATH, and how to check it from inside Claude Code (! which rapid).

---

3. Dependencies

The governance core still uses only the Python standard library. The installers need network access to clone the repository and to let pip fetch the build backend; optional integrations such as remote skills use Node.js/npx and need network access too.

---

4. Upgrade

curl -sL https://raw.githubusercontent.com/alyconr/Rapid-OS/v3.1.1/install.sh | bash   # Linux, macOS, WSL

irm https://raw.githubusercontent.com/alyconr/Rapid-OS/v3.1.1/install.ps1 | iex       # Windows

Then open a new terminal and check:

rapid --version                      # Rapid OS 3.1.1

If you installed with pip or pipx, upgrade with pip install --upgrade git+https://github.com/alyconr/Rapid-OS.git@v3.1.1 (or pipx install --force ...).

Rapid OS v3.1.0

Capa de intención (porcelain), cinco modos de ingeniería, shortcuts /rapid- y hooks de Claude Code. Notas: https://alyconr.github.io/Rapid-OS/release-v3.1.0 · Cambios: https://github.com/alyconr/Rapid-OS/blob/v3.1.0/CHANGELOG.md