Software development work resumed with updated rules BS1 active: Docker runtime work resumed under amended packet.
BS0 passed its independent review and is approved. BS1 is currently running under an updated configuration package, Docker engine software has been installed on the BS1 test system, and the team is waiting for the reviewer to approve the updated package before proceeding with installing and testing the OpenClaw container software. BS0 was approved on independent review. BS1 is active under an amended packet. Docker engine was installed on the BS1 fixture; OpenClaw container-instance runtime work is the next step pending the amended packet's reviewer approval.
Right now the team has just finished installing the core software engine on the test system and gotten approval to move forward with the next phase of work. The previous phase, which set up a basic test environment, was reviewed and approved. Now they're ready to start building out the control system that will keep everything running smoothly and monitor the overall health of the fleet.
This build is roughly one-third of the way through its planned journey. Before this, they had to set up the initial test environment from scratch. After this phase wraps up, they'll work on letting operators add new customers and manage their security credentials, then run a controlled test of the data ingestion system, expand to support more connection types, and finally prepare everything for upgrades, backups, and disaster recovery. The next major milestone is getting approval to continue with the control system work.
Roadmap click any sequence to expand
build-sequence-0 Fresh Provisioning Approved
Set up a new OpenClaw Instance for a test organization. Fresh-provision one OpenClaw Instance for one synthetic Org.
build-sequence-1 Stable Control Path And Fleet Watchdog Active
We're building a system to keep our control operations running reliably during disruptions and monitor the overall condition of our equipment fleet to catch problems early. Durable control path and fleet health model.
Objective
# Proposed Infrastructure Changes Replace the current SSH connection method for slice-0 with a more reliable reverse-connectivity tunnel (such as AW Gateway or Cloudflare's cloudflared tool), then add regular automated health checks to monitor all instances across the fleet. Replace or augment the slice-0 managed SSH local-forward control path with a stable AW Gateway/cloudflared or equivalent reverse-connectivity path, then strengthen recurring Instance health checks across the fleet model.
What it will deliver
- The system uses a secure reverse connection tool—like Cloudflare's cloudflared or similar software—to safely link your internal network to external services without opening direct firewall ports. AW Gateway/cloudflared or equivalent stable reverse connector.
- The system checks whether the communication pathway to the Gateway WebSocket—the intended normal route for data transmission—is accessible and working properly. Gateway WebSocket reachability through the intended steady-state path.
- The system tracks five status conditions: current (up-to-date information), stale (outdated information), unreachable (unable to connect), degraded (working but with reduced capability), and unknown (no data available). Status freshness model: current, stale, unreachable, degraded, unknown.
- The system runs regular automated checks to make sure everything is working correctly and catches any problems early. Recurring Watchdog checks.
- The system automatically identifies and categorizes different types of network disconnections so the team can quickly understand whether a connection dropped due to a client issue, server problem, or network infrastructure failure. Connection loss classification.
- We can set up automated notifications that trigger whenever a resource or system changes status, allowing your team to stay informed in real time without having to manually check for updates. Alert/event hooks for status changes.
Won't do (yet)
- The system will not accept or process data from Spawn. No Spawn ingestion.
- The test environment runs on separate infrastructure that does not contain actual customer data or connect to production systems. No real customer systems.
- I don't have enough context to rewrite this. Could you provide the technical text that needs to be revised for a mixed audience? No full Works Agent.
- The team is not currently setting up new communication or distribution methods for customers or partners. No channel onboarding.
- # No billing. The system is currently not recording or charging for usage. No billing.
- We are not currently performing any production work that spans multiple geographic regions. No production multi-region work.
build-sequence-2 Org Onboarding And Credential Collection Draft
We're setting up test accounts with fake customer information to train operators on how the system works and gather the login details they'll need for their work. Operator-driven onboarding and credential collection — no real customers.
Objective
# Operator-Driven Onboarding Workflow for New Organization Setup **Core Workflow** When a new organization joins, operators follow a guided checklist that collects required credentials (API keys, database connection strings, authentication tokens) through a secure form, then runs automated validation tests against a sandbox environment to confirm everything connects properly before the organization can access production systems. **Key Components** - **Credential Collection Form**: Operators enter each required credential one at a time with clear labels and help text; the system encrypts credentials immediately and never displays them after entry - **First-Run Validation**: Automated tests check that each credential works (by connecting to services, listing resources, or running test queries) and report pass/fail status with troubleshooting hints - **Sandbox Testing**: All validation happens in an isolated test environment that mirrors production but contains no real customer data - **Operator Checkpoints**: A final review step lets operators confirm all tests passed before marking the organization as ready for use This keeps new customers completely Turn synthetic Org setup into an operator-driven onboarding workflow for fresh provisioning, including credential collection design and first-run validation, without touching real customers.
What it will deliver
- An operator sets up a new organization account in the system to begin the setup process. Operator creates a new Org onboarding record.
- New users move through several stages as we set them up: we start with a draft profile, then wait for their credentials to arrive, verify those credentials work, check that everything meets our requirements, begin their account setup, confirm everything is working, or flag any problems that prevent moving forward. Onboarding state machine: draft, credentials pending, validation pending, ready to provision, provisioning, verified, blocked.
- The user interface for entering passwords and credentials saves only secure references (pointers to where the actual secrets are stored) rather than storing the sensitive information directly in the system. This approach keeps real passwords out of the application's database and reduces the risk of a data breach exposing them. Credential collection UX that stores only SecretRefs or fixture equivalents.
- # Credential Transition Design: Fixture to Real When we move from test credentials (fixture credentials used in development) to production credentials (real credentials used in live systems), we need a clear plan for how that handoff happens safely and securely. Fixture-to-real credential transition design.
- # Org Handoff Checklist When transferring organizational responsibilities to new team members, ensure you cover: - **Access and credentials**: Provide login information, permission levels, and system access needed to perform the role. - **Key contacts**: Share names and contact details for people they'll work with regularly across departments. - **Current projects and priorities**: Document what's in progress, deadlines, and what matters most right now. - **Tools and processes**: Explain the systems they'll use daily and the standard steps for common tasks. - **Documentation Org handoff checklist.
- # Policy/Baseline Selection The process of choosing which standard practices or rules to follow when building or managing a system—deciding, for example, whether to use stricter security settings or faster but less protected options. Policy/baseline selection.
Won't do (yet)
- The system is not processing new customer sign-ups or account creation at this time. No real customer onboarding.
- Don't use actual API keys (the security credentials that grant access to external services) in code or documents unless they've been specifically approved for a test environment that's isolated from live operations. No real provider API keys unless separately approved for a controlled non-production environment.
- The system will not accept or process data from Spawn. No Spawn ingestion.
- # Billing is Incomplete The invoice or charge statement is missing information or has not been fully processed yet. No full billing.
- There is no Works Agent available right now. No Works Agent.
- The company's different sales channels (like online, retail stores, and partners) aren't operating with the same pricing, product availability, or promotional offers. No broad channel parity.
build-sequence-3 Spawn Ingestion Dry Run Draft
We're testing our system's ability to handle incoming data using test fixtures (sample data) before processing real information. Controlled Spawn ingestion dry run with fixture systems only.
Objective
# Rewritten for Mixed Audience We can bring in a test version of the Spawn fixture (a simulated system component) to verify that our discovery tools find it, our classification system labels it correctly, our unwinding process can safely shut it down, and our audit logs capture all the details—all without affecting actual customer environments. Ingest a controlled Spawn-like fixture and prove discovery, classification, unwind planning, and evidence generation without touching real customer systems.
What it will deliver
- The team maintains a managed supply of spawn-like test fixtures (specialized equipment used to simulate real-world conditions in testing) to ensure consistent availability for quality assurance activities. Controlled Spawn-like fixture inventory.
- # Existing OpenClaw Discovery The OpenClaw security flaw has been found in systems that use this software library. Existing OpenClaw discovery.
- This system tracks all active components—including agents (automated workers), binding connections (communication links), sessions (active conversations), channels (communication routes), plugins (add-on tools), and tasks (work items)—to show what's running and how resources are being used. Agent/binding/session/channel/plugin/task inventory.
- # Tenant/Org Classification Workflow The system sorts customers and their organizations into categories based on size, industry, or contract type so that each one receives appropriate support and service levels. This classification happens automatically when a new customer signs up and can be updated manually if business needs change. Tenant/Org classification workflow.
- # Observe → Managed → Authoritative State Model The system moves through three stages: first it watches what's currently happening, then it takes action to match a desired configuration, and finally it enforces that configuration as the source of truth that overrides any manual changes. Observe -> Managed -> Authoritative state model.
- # Unwind Plan with No Destructive Execution We can reverse or stop the system changes we made while keeping all data and configurations intact, so nothing gets lost or damaged in the process. Unwind plan with no destructive execution.
Won't do (yet)
- # Spawn systems are test environments only and don't contain actual customer data. No real customer Spawn systems.
- The system will preserve all existing data and settings during the transfer to the new platform, so nothing will be lost or overwritten. No destructive migration.
- The system will not switch over to a backup automatically if the primary system fails. No automatic cutover.
- Team members must use separate, unique login credentials for each application and cannot reuse passwords across systems—except within approved test environments and secure credential storage systems that IT has authorized. No credential reuse outside approved fixture/vault paths.
- The system does not trust information from previous versions or earlier data states and instead verifies everything from scratch each time. No assumption that legacy state is trustworthy.
- The system doesn't balance workload across different channels beyond grouping them by fixture type. No channel parity beyond fixture classification.
build-sequence-4 Channel Onboarding Parity Draft
# Controlled Channel Onboarding Workflows New sales or distribution channels go through a structured approval process with defined checkpoints before they can start operating. Each step requires specific teams to review and sign off on requirements like pricing, inventory, and compliance before the channel can launch. Controlled channel onboarding workflows.
Objective
Teams can now set up communication channels with built-in approval processes and security controls, ensuring that designated priority channels stay protected while keeping organization-owned login credentials secure and maintaining a complete record of who accessed what information—with the ability to hide sensitive data when needed. Add controlled channel setup workflows for prioritized channels while preserving Org-owned credentials, auditability, and redaction.
What it will deliver
- We're setting up a step-by-step process to bring new sales channels online, with each channel following its own customized setup path based on its specific requirements. Prioritized channel onboarding flows, likely split by channel.
- Each communication channel (like email, messaging, or API connections) has its own separate set of login credentials and access tokens that must be managed and refreshed individually. Fixture credential/token handling per channel.
- When setting up tests or integrations, you need to register a web address where the system will automatically send notifications or data when specific events happen. This is similar to providing a mailing address so the system knows where to deliver messages. Webhook endpoint registration or fixture equivalent.
- The system sends regular test messages to communication channels to verify they're working properly and alert the team if any channels fail to respond. Channel status probes.
- The system records and tracks specific actions taken within each communication channel (such as email, chat, or phone) so teams can review who did what and when for compliance and security purposes. Channel-specific audit events.
- The organization applies different data-hiding standards depending on which communication channel is used—for example, email might require names and addresses to be removed, while a public website might need additional redaction of account numbers and payment information. Channel-specific redaction rules.
Won't do (yet)
- Don't use the same content across all sales channels (online, retail, phone, etc.) in a single release unless you've specifically divided the content by channel and gotten approval first. No all-channel parity in one slice unless explicitly split and approved.
- The system currently has no actual customer communication channels active in the production environment. No real production customer channels.
- The system does not store passwords or authentication tokens that work across all channels—each channel uses its own separate login credentials. No platform-wide channel credentials.
- All channel automation must work end-to-end without requiring people to manually step in and complete tasks that should happen automatically. No unsupported channel automation hidden behind manual steps.
- I don't have enough context to rewrite this. Could you provide the technical text you'd like me to simplify for a mixed audience? No Works Agent behavior expansion.
build-sequence-5 Operations, Upgrades, And DR Hooks Draft
# Key Operational Tasks for System Changes **Upgrade** means installing a newer version of software to gain new features or security fixes. **Rollback** means reverting to a previous version if problems occur. **Backup** means copying critical data to a separate location so it can be restored if something goes wrong. **Disaster Recovery (DR)** refers to the procedures and systems in place to restore operations after a major failure. **Operations readiness** means confirming that staff, processes, and systems are prepared to handle the change smoothly. Upgrade, rollback, backup, DR, and operations readiness.
Objective
**Operational Readiness Framework for AW** Establish clear ownership by defining who handles routine tasks, upgrades, and emergencies; create a documented upgrade process that tests changes before deploying them to production along with a plan to quickly reverse problematic updates; implement automatic backup procedures and tested recovery methods to restore data if needed; and prepare step-by-step disaster recovery guides that teams can follow during outages, while capturing incident details for later review. Formalize AW operational readiness: roles, upgrade policy, rollback, backup/restore hooks, disaster recovery runbooks, and incident evidence.
What it will deliver
- # MSP Role Matrix A role matrix for a Managed Service Provider (MSP) documents who performs what tasks, when they're responsible, and who approves decisions—helping teams stay aligned on responsibilities across different service areas. MSP role matrix.
- We're updating the canary flow—the process that gradually rolls out changes to a small group of users first before expanding to everyone—to improve how we test and monitor new features. Upgrade canary flow.
- The system verifies whether OpenClaw (a software tool) can work properly with your current setup and configuration. This check confirms that all necessary components are in place before you proceed with using the tool. OpenClaw compatibility check.
- # Rollback Policy and Dry-Run When deploying changes, a dry-run simulates the deployment without making actual changes, so your team can verify everything works correctly before going live. If problems occur after a real deployment, the rollback policy defines the steps to revert to the previous stable version quickly. Rollback policy and dry-run.
- The system saves a complete record of all backup storage locations and the instructions that trigger automatic restore actions, allowing teams to recover data quickly if needed. Backup inventory and restore hook definitions.
- # Disaster Recovery Runbook: Control-Plane and Instance-Host Failures ## Control-Plane Failure When the system's central management layer stops responding, immediately contact the infrastructure team to check hardware status, restart the affected servers, and redirect traffic to backup management systems while repairs are underway. ## Instance-Host Failure If individual application servers go down, the system automatically moves running applications to healthy servers; your team should verify that services are responding normally and alert the infrastructure team if any applications fail to restart within 5 minutes. DR runbook for control-plane failure and Instance-host failure.
Won't do (yet)
- Don't move forward with releasing this to all customers unless leadership gives explicit approval first. No full production launch unless separately approved.
- The team has not yet conducted a live test of the backup and recovery plan with actual customers involved. No real customer DR exercise.
- Work on a single region for now unless we explicitly plan a separate project for multi-region support. No multi-region implementation unless separately scoped.
- I'd be happy to help rewrite technical text for a mixed audience, but I don't see any text to rewrite in your message. Could you please share the technical content you'd like me to simplify? No billing or marketing.
- The system does not automatically update itself when running on actual production servers. No automatic upgrade across a real fleet.
Decisions locked, in writing, in the repo
Locked architectural questions
Foundational answers agreed during the initial design dialogue. Not up for renegotiation unless new evidence forces it.
Q1 OpenClaw Deployment Topology
OpenClaw runs on a variety of systems—from individual computers to company-owned servers in data centers—and typically operates multiple separate instances at larger organizations to keep different agents from interfering with each other, which is a core principle built into the system from the start.
Q2 Capabilities Manifest for Implementing Agent (Agent A)
# What Agent A Can Do Agent A (Claude Code with full capabilities) will set up OpenClaw on your local system, run through its complete startup process, gather documentation, and catalog your repository—then only report findings that it can point back to actual files or archived records.
Q3 Repository Context and Rebuild Scope
The team will rebuild Spawn's foundation from scratch while keeping all its current features intact, releasing pieces incrementally as backend and interface improvements work together—the original creator will verify features remain complete while the interface design improves where it makes sense. This pre-production work must set up the system to capture operational data as a side effect, so future products (like billing, analytics, and marketing tools) can build on that foundation later.
Q4 Follow-on Receiver (Who Implements)
Each build sequence item gets its own dedicated coding session where a developer writes and tests the code, then one approver reviews and approves the plan before implementation begins and the finished work merges into the main codebase.
Q5 Budget and Stopping Conditions
# Budget and Stopping Conditions The work will use up to 500 tool calls (requests to access files or systems) spread across the brief construction. Key documents get up to 100 calls each, supporting materials get 50, and informational files get 25. The team will run through a quality checklist three times to catch issues, compress the context (saved information) to 70% of its original size, and bring in an independent reviewer from a fresh session to approve early completion—with results saved to a verdict file and a maximum of three review requests allowed.
Q6 Tenancy Model (went through several revisions before locking)
# Tenancy Model – Simplified Overview The system organizes users and infrastructure into a hierarchy: one Service Provider manages multiple Customers (Orgs), each Customer may have multiple Tenants, each Instance (a physical gateway) belongs to exactly one Customer, and Agents run within each Instance. Each Instance serves only one Customer, and Tenants within the same Customer are completely isolated from each other—these rules are permanent and cannot be changed. Users are identified globally and can work for multiple Customers; Service Provider staff can view any Customer's setup for support purposes, and when migrating customers into the system, the person who performed the migration loses access to that Customer once the move completes.
Q7 Compliance and Security Architecture
# Compliance and Security Architecture The system includes a built-in AI assistant that helps staff members manage the control plane—the central system where configuration and access decisions happen. This assistant operates separately from the main application platform itself, running in a different infrastructure location for each organization to maintain isolation and security. The assistant respects user roles and organization boundaries, restricting what each person can see and do based on their permissions.
Recent decisions (14)
Architecture decisions logged as they're made. Newest first.
2026-04-26 Linux OpenClaw runtime is containerized architecture
OpenClaw runtime must run in containers on Linux systems, with host-native installations allowed only on macOS or for temporary administrative tools—never for production use. To validate readiness on Linux, teams must gather evidence from the containerized OpenClaw runtime running through Docker, with the Gateway exposed only through a loopback connection on the Debian host for managed SSH access.
- Decision
- Linux OpenClaw runtime Instances must run as Docker/containerized runtimes. Host-native OpenClaw runtime is allowed only as a macOS host exception. Host-native Linux OpenClaw CLI installs may exist only as exploratory/admin tooling and must not be used as production runtime, Gateway supervisor, or Linux readiness pass evidence.
- Reason
- BS1 must prove the durable Anthropy Works runtime shape for Linux hosts. Using host-native Linux OpenClaw Gateway or host-native Linux CLI doctor/status output would validate the wrong operating model and could hide container supervisor, volume/state, network binding, and cleanup risks.
- Impact
- BS1 runtime work is paused until resumed under the amended packet. Linux readiness evidence must come from the Docker/containerized OpenClaw runtime, with Gateway exposure constrained to a Debian-host loopback publish path for the managed SSH forward. The accidental exploratory host-native Linux CLI install on `s187-u007.manifest0.net` was cleaned up and documented in BS1 evidence.
- Review status
- active for BS1.
- Sources
- User architecture clarification on 2026-04-26; amended `docs/aw-handoff/06-agent-team-execution/build-sequence-queue/build-sequence-1-stable-control-path-and-fleet-watchdog/SEQUENCE-PACKET.md`.
- Rollback path
- Do not reintroduce host-native Linux OpenClaw runtime without a new architecture decision and explicit user approval. If OpenClaw container operation cannot satisfy BS1 gates, stop and amend the packet rather than falling back to host-native Linux runtime.
2026-04-26 AW deployment architecture: multi-tenant reverse-proxy (HetzClaw pattern), Traefik selected architecture
# AW Deployment Architecture Overview The standard setup uses a reverse-proxy server (Traefik) running on each host machine to direct incoming requests to the correct organization based on the request's hostname, with each organization running in its own isolated container group that connects to a shared network for discovery and communication. This approach eliminates the need to manually manage ports or maintain a separate registry—the proxy automatically finds each organization's containers through configuration labels.
- Decision
- The authoritative AW deployment architecture for hosting Linux containerized OpenClaw runtime Instances is the **HetzClaw multi-tenant pattern**: - **One reverse-proxy stack per host** (Traefik plus a `tecnativa/docker-socket-proxy` hardening layer). Listens externally and routes to per-Org gateways by Host header. - **One compose stack per Org Instance.** Each Org's OpenClaw gateway is a separate compose stack at `/var/lib/aw/orgs/<orgid>/`, with its own per-Org token, per-Org config volume, per-Org workspace volume, and per-Org Traefik routing labels. - **Shared `aw-proxy` Docker bridge network.** Both the proxy stack and every Org stack join this network. The proxy auto-discovers each Org via Docker labels; no manual registry, no port allocation. - **No host-side port publish for any Or
2026-04-26 AW naming convention for tenants, Instances, stacks, and artifacts architecture
# How We Name Things in Our System We've established a single naming standard that applies to all our managed components—from customer organizations and server instances to services, containers, and configuration files. This standard ensures that every component's name can be predictably recreated from a few key pieces of information: the organization identifier, the component's role, when it was set up, and which service it belongs to. We're using names that people can read and understand, that won't accidentally collide with other names, and that stay consistent throughout a component's lifetime. This standard takes effect immediately for our current build cycle and all future deployments, unless we make an official change to it.
- Decision
- This document fixes the naming convention for every AW-managed artifact: tenants (Orgs), Instances, compose stacks, services, containers, hostnames, filesystem paths, secrets, networks, Traefik routing labels, systemd units, and Docker labels. It applies to BS1 immediately and to all subsequent Build Sequences and production deployments unless amended by a new dated decision. The core rule: **every artifact's name is deterministically derivable from a small set of identifiers** — Org slug, role, provisioning timestamp, service-within-stack — and those identifiers are themselves chosen to be human-legible, collision-free, and stable across the artifact's lifetime.
2026-04-26 Debian 13 (trixie) accepted as BS1 P2 production-like fixture release governance
Debian 13, the latest version of the free operating system, has been approved for use in production-like test environments with standard priority status. This means teams can now use it to test software and systems in conditions that closely match real production setups.
2026-04-26 OpenClaw Linux container runtime: `ghcr.io/openclaw/openclaw` is the authoritative artifact source architecture
# OpenClaw Linux Runtime Source When running OpenClaw on Linux in containers at Anthropy Works, always pull the official runtime from `ghcr.io/openclaw/openclaw` maintained by the OpenClaw team; do not substitute custom-built versions for production work without explicit approval. For macOS machines or one-time command-line tasks, the `npm install openclaw` installation method remains the standard approach.
- Decision
- For all Linux containerized OpenClaw runtime work in Anthropy Works, the **authoritative source of the OpenClaw runtime container artifact is the OpenClaw maintainers' own GitHub Container Registry path**: ``` ghcr.io/openclaw/openclaw ``` Henceforth: - Linux OpenClaw runtime Instances pull from `ghcr.io/openclaw/openclaw:<pinned-version>`. - Custom-built OpenClaw runtime images are not authoritative for production evidence and must not be substituted for the upstream image without a new architecture decision. - The `npm install openclaw` install-cli path remains authoritative for **macOS** host-native runtime (where the container boundary is exempt by the 2026-04-26 Linux-container decision) and for any non-runtime workflow such as one-shot CLI use, but is not the authoritative path for *
2026-04-25 Run workspace isolation operational
Create a separate workspace for the Codex Build Sequence 0 process that stores all outputs in the `runs/codex-bs0/` folder instead of the main system directory, which prevents Codex results from mixing with other build processes and keeps the application code in `runs/codex-bs0/app/` and all related review materials in `runs/codex-bs0/`.
- Decision
- Execute the Codex Build Sequence 0 run under `runs/codex-bs0/` instead of the master architecture root.
- Reason
- Keeps Codex outputs isolated from any Claude Code build-off run.
- Impact
- Implementation repo lives at `runs/codex-bs0/app/`; evidence/review paths live under `runs/codex-bs0/`.
- Review status
- pending orchestrator close review.
- Sources
- `DUAL-ORCHESTRATOR-RUNBOOK.md`, `RUN-ISOLATION-MANIFEST-CODEX.md`.
- Rollback path
- Move or archive the run root after close; do not merge outputs into master without review.
2026-04-25 Local bootstrap verification while pnpm is unavailable operational
When the package manager pnpm isn't installed yet, run initial verification checks using Node's built-in TypeScript support instead of waiting for pnpm, then install pnpm afterward to maintain the locked versions in package.json for testing frameworks and dependencies. The first setup step must complete only after confirming pnpm is either available or the missing tool has been addressed.
- Decision
- Preserve the pinned `pnpm`/Vitest/Playwright/Next stack in `package.json`, but use Node native TypeScript tests for the first local bootstrap check.
- Reason
- Current host has Node but no `pnpm`; switching package managers would violate the sequence pin.
- Impact
- Sequence 0 cannot close until `pnpm` path is installed and evidenced or the environment gap is resolved.
- Review status
- superseded by the local bootstrap green decision below; this was not a closure waiver.
- Sources
- `BUILD-SEQUENCE-FRESH-PROVISIONING.md` stack pins.
- Rollback path
- Install `pnpm`, run pinned test/build/e2e commands, and replace local bootstrap evidence with final evidence.
2026-04-25 Local bootstrap green with patched dependency set operational
The local development environment now runs successfully with all patches applied and testing complete—the build uses the pinned software versions and generates documentation that reviewers can examine. The remaining work requires access to remote deployment infrastructure (SSH, OpenClaw, and Gateway systems) rather than local tools.
- Decision
- Treat the local scaffold as bootstrap-green after installing workspace-local `pnpm@10.10.0`, resolving the patched dependency lockfile, and passing Vitest, TypeScript, static scan, and Next production build.
- Reason
- The local build no longer depends on the earlier Node-native fallback; it now exercises the pinned stack and produces reviewer-readable evidence.
- Impact
- Remaining blockers are host-level SSH/OpenClaw/Gateway evidence, not local toolchain availability.
- Review status
- accepted as bootstrap status only; Sequence 0 remains open.
- Sources
- `runs/codex-bs0/architecture-rebuild-evidence/build-sequence-0/codex-bs0/manifest.json`.
- Rollback path
- If later host evidence forces code changes, rerun the local verification bundle and update this decision with the new commit.
2026-04-25 Next.js security patch pin security
The team needs to update Next.js from version 15.3.1 to 15.3.8 in the Build Sequence 0 to fix a security vulnerability in React Server Components. After making this change, the hosting preparation step must run dependency installation again to ensure the lockfile pulls in the patched version.
- Decision
- Update the Build Sequence 0 Next.js pin from `15.3.1` to `15.3.8`.
- Reason
- `next@15.3.1` is affected by the React Server Components/Next.js security advisories, including CVE-2025-66478. The later Next.js December 11, 2025 advisory lists `15.3.8` as the patched version for the 15.3.x line.
- Impact
- Host prep must rerun dependency install after this change so the lockfile resolves the patched Next.js version.
- Review status
- accepted as security patch.
- Sources
- https://nextjs.org/blog/CVE-2025-66478 and https://nextjs.org/blog/security-update-2025-12-11.
- Rollback path
- Do not roll back to vulnerable 15.3.1. Future upgrades may move to a newer patched Next line after security review.
2026-04-25 OpenClaw install evidence source operational
# Rewrite When installing OpenClaw, use the official installer provided by the vendor and record which version actually gets installed when you run the setup, rather than assuming an older version will be used. Before confirming the installation is complete, check whether the commands that ran match what was expected and note any differences.
- Decision
- Use OpenClaw's official installer path for host-level Sequence 0 evidence and record the resolved installed version at execution time instead of pinning an old OpenClaw release in the app scaffold.
- Reason
- OpenClaw's own release policy is beta-first/stable-promoted, and the execution docs require Packet 5 to resolve and record the current stable version during the run.
- Impact
- Host evidence must cite the installer/version actually used and classify any command drift before claiming acceptance.
- Review status
- accepted as host-evidence policy.
- Sources
- https://docs.openclaw.ai/install and https://docs.openclaw.ai/RELEASING.
- Rollback path
- If the current installer or latest stable cannot satisfy a Sequence 0 acceptance command, stop and classify the drift under `DRIFT-CONTROL.md`.
2026-04-25 Host fixture and Gateway evidence passed operational
The testing infrastructure confirms that a disposable Debian 12 container running a real SSH server meets the requirements for the initial build phase, and the OpenClaw Gateway should run as a foreground process rather than as a background service since the container lacks systemd support. The current test validates that SSH access, OpenClaw installation, Gateway startup, and basic communication all work correctly, but production-environment behavior still needs to be verified separately on infrastructure that matches the actual production setup.
- Decision
- Treat the disposable Debian 12 Docker SSH container as the valid Build Sequence 0 SSH fixture target and use OpenClaw foreground Gateway mode inside that container.
- Reason
- The fixture is a real SSH daemon reachable over TCP and satisfies the approved fixture class. The container does not provide systemd, and OpenClaw's own runtime output instructs container users to run the Gateway in the foreground instead of the systemd service path.
- Impact
- BS0 host evidence proves SSH execution, OpenClaw install/readiness, Gateway startup, and a WebSocket read probe. Production supervisor behavior remains outside this container fixture proof and must be covered on a production-like host in a later sequence.
- Review status
- ready for independent review.
- Sources
- `runs/codex-bs0/architecture-rebuild-evidence/build-sequence-0/codex-bs0/host-sequence0-summary.md`, `gateway/foreground-start.log`, `gateway/websocket-read-probe.log`.
- Rollback path
- Re-run host evidence against a non-container Debian SSH host with systemd when production supervisor proof is required.
2026-04-25 Gateway auth material uses SecretRef plan security
# Use OpenClaw's secrets command to store gateway authentication tokens safely Apply the `gateway.auth.token` and `gateway.remote.token` credentials through OpenClaw's `secrets apply` command (which uses the SecretRef plan) rather than entering them as plaintext with the `openclaw config set` command. The secrets command encrypts credentials and passes the `OPENCLAW_GATEWAY_TOKEN` environment variable at runtime, which ensures the tokens meet security requirements and pass OpenClaw's audit checks.
- Decision
- Apply `gateway.auth.token` and `gateway.remote.token` through an OpenClaw `secrets apply` SecretRef plan using `OPENCLAW_GATEWAY_TOKEN` as the fixture runtime source, rather than writing token plaintext through `openclaw config set`.
- Reason
- The first Gateway evidence attempt produced a working WebSocket path but failed `openclaw secrets audit --check` because token fields were stored as plaintext. The SecretRef plan path is the documented OpenClaw credential projection surface and satisfies the AW no-plaintext credential boundary.
- Impact
- Secrets audit is clean with plaintext `0`, unresolved `0`, shadowed `0`, and legacy `0`.
- Review status
- ready for independent review.
- Sources
- `runs/codex-bs0/host-prep/openclaw-gateway-secretref-plan.json`, `openclaw/gateway-secretref-plan-apply.log`, `openclaw/secrets-audit.log`.
- Rollback path
- Do not revert to plaintext config. If OpenClaw changes the SecretRef plan schema, update the plan and re-run the audit.
2026-04-25 Build Sequence 0 evidence ready for independent review governance
The initial set of evidence has passed all automated checks (application functionality, user interface testing, infrastructure verification, encrypted communication validation, and security credential review) and is now available for an independent reviewer to examine—but the work cannot be marked as fully complete until that reviewer approves it. No subsequent work phases should proceed or be marked finished until the reviewer's decision is received and incorporated.
- Decision
- Mark the Codex BS0 evidence bundle as `ready-for-independent-review`, not complete.
- Reason
- App checks, UI E2E, host evidence, Gateway WebSocket proof, and secrets audit are green. The approved execution model still requires independent review before the slice can be marked done.
- Impact
- No further build work should be claimed complete until reviewer verdict is received. Future sequence packets remain draft/not executable until BS0 review outcome is incorporated.
- Review status
- pending independent reviewer.
- Sources
- `runs/codex-bs0/architecture-rebuild-evidence/build-sequence-0/codex-bs0/manifest.json`, `REVIEWER-HANDOFF.md`.
- Rollback path
- If reviewer finds blockers, reopen BS0, patch, re-run evidence, and update this decision.
2026-04-25 Build Sequence 0 approved and closed governance
Build Sequence 0 has been approved and closed after an independent reviewer confirmed no blocking issues were found. The seven remaining findings are scheduled for Build Sequence 1, and the team should now move forward with preparing and approving the next build packet unless a regression requires returning to this sequence.
- Decision
- Mark the Codex Build Sequence 0 run complete after independent reviewer approval.
- Reason
- The isolated reviewer returned `Verdict: approve` with no blocking findings and explicitly stated that Build Sequence 0 can be marked complete. The seven findings are non-blocking carry-forward requirements for Build Sequence 1, not BS0 rework.
- Impact
- BS0 is closed. Build agents must not continue adding BS0 scope unless a regression is discovered. The next executable work is preparing and approving the Build Sequence 1 packet.
- Review status
- approved and closed.
- Sources
- `runs/codex-bs0/architecture-rebuild-review/build-sequence-0/isolated-review-workspace/outputs/reviewer-verdict.md`, `runs/codex-bs0/architecture-rebuild-evidence/build-sequence-0/codex-bs0/BS0-CLOSEOUT.md`.
- Rollback path
- If a later reviewer or production-host proof finds a BS0 blocker, reopen BS0 with a new dated decision, patch the defect, re-run affected evidence, and request a fresh independent review.
Stable Control Path And Fleet Watchdog — checkpoints 12 recorded
Current gate
- Packet amendment review
- Pass BS1 packet amendment approved; ready for renewed user approval before Docker runtime proof
- Amended packet committed
- Pass
- Docker / containerized runtime proof
- In progress Docker engine installed (runs/codex-bs1/architecture-rebuild-evidence/build-sequence-1/codex-bs1/checkpoints/checkpoint-009-docker-engine-install.md); runtime container work not yet started.
Architecture warning
Evidence hygiene
- Redaction status
- applied
- No real customer data
- Pass
- No real provider credentials
- Pass
- No raw secret material exposed
- Pass