Decentralized Coding: Beta

Short Version

This is a simple shared workspace for building an open source project in public through one project chat and one GitHub repo.

The first public phase is the 6529 AMM hook. Builders talk in project chat, turn one idea into a small proposal, record the decision, build a draft PR, review it, and share the result back with a clear log.

The same loop can become reusable infrastructure later. For now, the product stays focused on one successful hook build.

The builder flow is:

1. Choose the hook project.
2. Read what is happening now.
3. Chat with builders.
4. Suggest one small change.
5. Record the project decision.
6. Build the PR.
7. Review before humans merge.
8. Share the update.

The simple product shape is:

Project -> Discuss -> Decide -> PR -> Review -> Log

Current Status

This repo is an MVP prototype for one public hook-building project. The pilot is the 6529 AMM hook, with a 6529 wave as the first project chat source. It is intentionally scoped to prove one clear loop before it becomes a broader builder protocol.

What exists now:

• A Next app product surface called Decentralized Coding: Beta, focused on helping builders work together in public.
• One active hook project with project chat and an intentional placeholder GitHub repo until maintainers choose it.
• EIP-712 wallet ownership verification with a five-minute challenge, 24-hour HttpOnly session, logout, origin checks, and explicit pre-admission permissions.
• Orchestrator identity set to the 6529 account daemon.
• Review agent and GitHub repo are explicit placeholders for this phase until the reviewer process and first repo are selected.
• A work-first public workspace with the pilot rules decision, open work, group discussion, pull requests, contributors, proposed rewards, and public proof status on one screen.
• Simple work types: Code PR, Question, Update, and Context.
• Copyable drafts for chat posts, join messages, decisions, review requests, project updates, launch packets, Codex work packets, and contribution reports.
• Hook proposal checks for caps, tests, upgradeability, deployment, governance, payments, and live-holder authority claims.
• Per-instance rate limits for public read routes, direct chat posting, and protected chat sync.
• Direct chat posting is admin-protected, IP-limited, and paced by the current daemon setting for each builder.
• Successful chat posts record a daemon-observed project event from the shared conversation, including PR links, decisions, reviews, repo setup, suggested work, or questions when daemon detects them.
• Protected chat sync can import the latest visible builder posts into daemon-observed project state without duplicating prior observations.
• Public daemon summaries redact obvious credentials before they enter project state.
• Pulled chat previews use the same redaction before display or contribution reporting.
• Timeout and response-size bounds around external 6529, GitHub, setup, launch, and smoke-check fetches.
• Client request timeouts so UI actions fail clearly instead of hanging.
• Scoped API routes for setup, proposals, local votes, decision links, PR records, reviews, launch audit, setup proof, and public project state.
• Public active project index for agents or future UI surfaces that need the hook list, project chat links, latest changes, group chat settings, current vote, discussion topics, PR rows, member summaries, and agent ownership.
• Public project snapshot with daemon-managed summary, changelog, current vote, discussion topics, PR status, project rules, and agent status.
• Public verification manifest lists itself, setup proof, state, project index, launch audit, chat launch, chat posting capability, launch track status, and required hash fields.
• Public project state includes a full snapshot hash, so setup checks can detect stale or edited state payloads.
• Shared JSON body validation for API routes so malformed, non-object, or oversized request bodies fail clearly.
• A deterministic reviewer foundation with PR manifests, guardian attestations, proof replay, risky path checks, and hook contract signal checks.
• Setup proof omits placeholder GitHub repo values and blocks required-check verification until the real repo is selected.
• Setup validation checks the selected hook repo for contributor rules, the PR template, the guardian workflow, and the required guardian check.
• Chat launch proof includes a Group discussion item. It is ready only after daemon has parsed at least one builder message.
• Launch audit, workflow proof, checklists, launch packets, update drafts, and contribution reports reject stale PR or review evidence unless the PR link and review proof are bound to the configured repo.
• Review cannot record guardian proof unless the current execution includes a PR link for the configured repo.
• Review records a bounded PR comment and check run before saving reviewer proof.
• GitHub guardian PR evidence includes the target repo and fails when it does not match the configured hook repo.
• The GitHub adapter can prepare branches from a selected base, commit bounded text files, open draft PRs, post bounded PR comments, and create bounded check runs. It still does not merge, deploy, or change repo settings.
• Local file storage for the demo flow and optional Postgres storage via db/001_command_waves.sql.

What remains manual or MVP-only:

• Chat posting works when a 6529 bot wallet is configured. Without bot credentials, the app drafts text for a human to post manually.
• Wallet ownership can be verified, but GitHub linking, REP or challenge eligibility, membership, and seat selection are not implemented. A wallet session grants no chat, claim, vote, merge, or reward authority.
• The current signature verifier supports EVM externally owned accounts. Smart contract wallets require a configured chain RPC and EIP-1271 verification before they can sign in.
• Local votes are app records. PR work requires a manually recorded project decision URL before code work starts.
• Codex execution prepares a branch, commits a bounded work packet plus optional approved text files, and opens a draft PR record. It does not yet run an isolated code-writing worker.
• The GitHub repo is a placeholder in the default project state. Chat can launch first, but PR work waits until maintainers choose the repo.
• The GitHub adapter can prepare branches, commit bounded text files, open draft PRs, post bounded PR comments, and create bounded check runs when configured. It does not merge, deploy, change repo settings, or spend funds.
• The current guardian runs as a repo-local GitHub Action. The stronger production version should be an external GitHub App.
• Contribution reporting is a daemon-generated visible-activity analysis with partial confidence. It uses visible app activity, daemon-observed project chat, recorded PR links, and repo-bound review proof. Agent and system log events stay in the audit trail but do not become member score. Builder profiles show activity, voting summaries, and report points as context only. Full scoring across unattached GitHub commits, merges, and off-app activity is still future work.
• The default demo includes approved work and decision activity. daemon-observed group discussion appears after builders post through the app or after chat is pulled into app state. The default placeholder repo keeps PR work blocked until maintainers choose the repo.

What we are working on next:

1. Pick the first real public project chat.
2. Keep the GitHub repo as a placeholder until maintainers choose it.
3. Configure launch env, durable storage, and daemon chat posting.
4. Record the first daemon-observed group discussion message.
5. Add the selected hook repo, reviewer process, guardian workflow, and required guardian check before the first PR.
6. Finish the first public loop: discussion, scoped proposal, project decision, PR record, reviewer proof, and share-back.
7. Add GitHub identity linking, eligibility receipts, and deterministic builder admission on top of signed wallet sessions.
8. Expand contribution analysis after the workflow is useful and understandable.

Why This Exists

Agents can help builders move faster, but broad agent permissions get risky when a group is moving quickly. In phase 1, agents only help with reads, drafts, chat updates, and PR work after the rules allow it.

The app makes the important answers visible:

• Who decided this work should happen?
• Did the work need a vote?
• Did quorum pass?
• What tool or agent prepared the work?
• What changed?
• Was the result reviewed?
• Can humans audit the chain later?

MVP

The first public phase:

1. Choose one public project chat.
2. Keep the GitHub repo placeholder through chat launch, then connect one repo when maintainers choose it.
3. Record join requirements such as reputation, token, allowlists, or QnA as advisory until live enforcement exists.
4. Propose hook work in plain English with clear limits.
5. Let orchestration rules classify risk and require votes for important changes.
6. Let an agent help produce a PR when allowed.
7. Review the PR in CI against the approved proposal, rules, and hook guardrails.
8. Show recent activity and a transparent contribution report.
9. Keep the full audit log available.

No auto-merges, autonomous deploys, spending, or live REP/TDH authority in the first phase.

Launch operating notes are in docs/first-hook-launch-playbook.md. Contributor rules for the first hook phase are in CONTRIBUTING.md.

Trust Boundary

The first public phase is a governed hook-building workflow controlled by one public project chat.

Current trust controls:

• The MVP guardian is a repo-local GitHub Action named Command Waves Guardian.
• PRs must carry a Command Waves manifest that ties code changes back to an approved project proposal.
• The guardian writes replayable proof artifacts: guardian-attestation.json, guardian-wave-state.json, and guardian-pr-evidence.json.
• npm run guardian:verify-proof replays the guardian decision from those artifacts.
• Setup proofs now disclose the current guardian mode as repo_local_github_action and mark it as mvp strength.
• Guardian/reviewer/setup-proof code changes are treated as critical-risk diffs.

The most important production hardening step is moving from the repo-local GitHub Action to an external GitHub App. The app should own the required check, read the public project state, replay the same deterministic verifier, and publish the same proof artifacts. Until then, the MVP is useful and auditable, but not the strongest possible trust boundary.

First launch tasks:

1. Pick the first real project chat, keep the repo placeholder for chat launch, then publish the launch playbook.
2. Set COMMAND_WAVE_STATE_URL to the deployed /api/command-wave/state endpoint before making the guardian a required PR check.

Hardening tasks after the first public loop:

1. Move the guardian into an external GitHub App, keeping the verifier as the shared core.
2. Replace approved-file PR setup with a controlled Codex harness that writes bounded code patches in an isolated worker.
3. Expand contribution reports from app activity into full wave history, GitHub commits, merges, and off-app review notes.

Lessons Reused From 6529arena

See docs/6529arena-lessons.md for the full transfer.

Short version:

• Keep the public project chat as the social source of truth.
• Use the app as the control panel for setup, rules, jobs, and audit views.
• Reputation can route work, but permissions are the real security boundary.
• Agents request actions; the app decides what is allowed.
• Design for local mock mode first, then production adapters.
• Log every meaningful state transition.

Current App

The root screen is the first implemented slice of the product reset described in docs/product-reset-plan.md. It is an active build workspace rather than a launch or governance dashboard.

The public workspace now leads with:

• The 6529 AMM Hook goal and current pilot status.
• The 50-builder cap, proposed contributor share, repo state, and reviewer state.
• The first rules decision and the current milestone.
• Open contract, setup, and test work without fake claims or payout credits.
• Inspectable work pages with scope, constraints, roles, decision state, code status, and repo-bound evidence.
• One natural group discussion with automatic design and review filters.
• Pull requests, contributor profiles, project rules, and public proof states.

Local preview mode deliberately hides seeded votes, demo profiles, and test chat messages. Wallet connection now requires an EIP-712 signature and creates a server-verified HttpOnly session. The session proves wallet ownership only. Signed membership, GitHub identity, fair admission, payout credits, and direct live member posting are not implemented yet. The interface labels those boundaries instead of presenting them as working authority.

Existing backend foundations remain available for continued development:

• 6529 context, normalization, redaction, sync, and posting adapters.
• GitHub repo, branch, PR, comment, check-run, and evidence adapters.
• Hook proposal, diff, fee-bound, upgradeability, deployment, and governance checks.
• Public state, launch audit, setup proof, verification manifest, and contribution report endpoints.
• Copied launch status separates chat launch gaps from PR-loop gaps so maintainers do not overstate readiness.
• Local file storage and optional Postgres storage via db/001_command_waves.sql.

The next product slices add GitHub identity, deterministic admission, durable discussion sync, work roles, signed decisions, the independent reviewer, task credits, challenges, and reproducible reward proofs.

Run Locally

npm install
cp .env.example .env.local
npm run dev

Open the local URL printed by Next.

6529 mock mode is the safe default. Set 6529_MOCK_MODE=false only when you are ready to use the live 6529 API. Chat posting also requires 6529_BOT_BEARER_TOKEN and 6529_BOT_WALLET_ADDRESS; otherwise builders can copy the message and post manually.

With the example env, command-wave demo state is stored in .data/command-wave.json.

Before opening a PR, run the local quality check:

npm run verify

This regenerates Next route types before TypeScript, runs lint and tests, checks for em dash or en dash characters, and builds the app.

First Public Launch Env

Before inviting broad participation, set the first-loop launch variables:

NEXT_PUBLIC_APP_URL=https://your-app.example
COMMAND_WAVE_STORE=postgres
DATABASE_URL=postgresql://user:password@host:5432/command_waves
ADMIN_API_KEY=<strong random key>
WALLET_SESSION_SECRET=<strong random secret with at least 32 characters>
COMMAND_WAVE_INITIAL_NAME="6529 AMM hook"
COMMAND_WAVE_INITIAL_WAVE_URL=https://6529.io/waves/your-hook-project
# Intentional placeholder. Keep this until maintainers choose the hook repo.
COMMAND_WAVE_INITIAL_REPO_URL=https://github.com/your-org/your-hook-repo
6529_MOCK_MODE=false
6529_BOT_BEARER_TOKEN=<6529 bot token>
6529_BOT_WALLET_ADDRESS=<6529 bot wallet address>
COMMAND_WAVE_STATE_URL=https://your-app.example/api/command-wave/state
COMMAND_WAVE_GUARDIAN_REQUIRED_CHECK="Command Waves Guardian"
COMMAND_WAVE_REPO_ADAPTER=github
COMMAND_WAVE_GITHUB_TOKEN=<github token>

Use .env.production.example as the deployment checklist.

COMMAND_WAVE_INITIAL_WAVE_URL seeds the first project chat. COMMAND_WAVE_INITIAL_REPO_URL stays as a placeholder until maintainers choose the hook repo. Chat launch readiness allows the placeholder repo, but still requires daemon to parse at least one builder message. Full PR-loop readiness blocks PR work until a real repo is selected. ADMIN_API_KEY protects setup, proposal, vote, run, review, and reset actions. WALLET_SESSION_SECRET signs wallet challenges and sessions. Development can use an ephemeral process key, but production fails closed without a strong configured value. COMMAND_WAVE_STATE_URL gives guardian PR checks the public wave state. COMMAND_WAVE_GUARDIAN_REQUIRED_CHECK names the check that must be required in GitHub branch protection or rulesets. The chat-first launch requires daemon chat posting credentials, durable storage, and daemon-observed group discussion evidence. A ready PR loop also requires the selected reviewer process, GitHub PR adapter, guardian workflow in the selected hook repo, and the required guardian check so the public workflow can record draft PRs predictably.

The local demo still reports launch gaps until the first hook chat is reachable, ADMIN_API_KEY, WALLET_SESSION_SECRET, NEXT_PUBLIC_APP_URL, durable storage, live 6529 mode, daemon chat posting credentials, daemon-observed discussion evidence, and setup validation are configured. PR-loop readiness also requires the selected hook repo, selected reviewer process, GitHub PR adapter, guardian state, guardian workflow, and required guardian check.

Durable Storage

For a small first loop, local file storage can prove the chat-to-PR workflow while 6529 holds the public discussion and decision links. Before broad participation, use Postgres so setup, proposals, votes, decisions, PR records, reviews, and ledger events survive server restarts.

1. Create a Postgres database.
2. Apply the schema:

psql "$DATABASE_URL" -f db/001_command_waves.sql

3. Configure the app:

COMMAND_WAVE_STORE=postgres
DATABASE_URL=postgresql://...

4. Verify storage appears as production durable:

SETUP_REQUIRE_PRODUCTION_STORAGE=true \
SETUP_PROOF_URL=https://your-app.example/api/command-wave/setup/proof \
npm run setup:verify

Guardian Check

The repo includes a first GitHub Actions check named Command Waves Guardian.

Run the same deterministic verifier checks locally:

npm run guardian:check

Run the PR record adapter against a GitHub pull request event:

GITHUB_EVENT_PATH=event.json COMMAND_WAVE_STATE_PATH=wave.json npm run guardian:pr-check

Replay a published guardian proof artifact:

GUARDIAN_ATTESTATION_PATH=guardian-attestation.json \
GUARDIAN_WAVE_STATE_SNAPSHOT_PATH=guardian-wave-state.json \
GUARDIAN_PR_EVIDENCE_PATH=guardian-pr-evidence.json \
npm run guardian:verify-proof

For local demos only, set COMMAND_WAVE_ALLOW_DEMO_STATE=true to use the built-in demo wave state.

When the PR adapter runs in GitHub Actions, it writes guardian-attestation.json, writes the exact guardian-wave-state.json snapshot it checked, writes guardian-pr-evidence.json, appends a Markdown proof summary to the job summary, replays the proof, and uploads the files as a guardian-proof workflow artifact.

The attestation includes hashes of the project state, proposal, poll, rules, PR manifest, and changed paths. The replay script recomputes the guardian result from the uploaded artifacts. That is the simple fairness proof: anyone with the same inputs can rerun the deterministic guardian and get the same result.

This is the simple first step. The PR adapter feeds changed paths, PR manifests, and wave state into the same verifier so GitHub can block merges that do not match the project rules. Pull requests without a Command Waves manifest fail the guardian check instead of bypassing it.

The current guardian enforcement mode is repo_local_github_action. That is good enough for the MVP because guardian code and workflow changes are treated as critical-risk PRs, but the stronger production version should move the check into an external GitHub App so the governed repo cannot edit its own reviewer.

The setup proof can advertise the production guardian by setting:

• COMMAND_WAVE_GUARDIAN_MODE=external_github_app
• COMMAND_WAVE_GUARDIAN_REQUIRED_CHECK=<external app check name>
• COMMAND_WAVE_GUARDIAN_PROOF_ARTIFACT=<artifact name>

Before making Command Waves Guardian a required GitHub check, copy .github/workflows/guardian-review.yml into the selected hook repo and configure one real wave-state source for the workflow:

• COMMAND_WAVE_STATE_URL, usually https://your-app.example/api/command-wave/state
• COMMAND_WAVE_STATE_PATH

To open real GitHub PRs from prepared agent branches, configure:

• COMMAND_WAVE_REPO_ADAPTER=github
• COMMAND_WAVE_GITHUB_TOKEN or GITHUB_TOKEN
• COMMAND_WAVE_GITHUB_BASE_BRANCH, optional, defaults to main

The GitHub adapter prepares same-repo branches, commits bounded text files, and opens draft PRs from those branches. It rejects fork refs, raw SHAs, tags, and ambiguous refs. It does not merge PRs, deploy contracts, change repo settings, or spend funds.

Verify a published setup proof against GitHub required-check payloads:

SETUP_PROOF_URL=https://your-app.example/api/command-wave/setup/proof npm run setup:verify

If GitHub returns 404 for a rules endpoint, the verifier prints GITHUB_TARGET_UNAVAILABLE and continues. If another setup target cannot be fetched, it prints SETUP_TARGET_UNAVAILABLE. The audit still fails unless the required evidence is found.

When the setup proof includes commandWaveStateUrl, the same command also checks that the state URL returns a command-wave-state-v0.1 snapshot for the governed project with a matching state hash.

For a stricter production audit that fails until the guardian is external to the repo:

SETUP_REQUIRE_EXTERNAL_GUARDIAN=true \
SETUP_PROOF_URL=https://your-app.example/api/command-wave/setup/proof \
npm run setup:verify

For a stricter durable-storage audit before broad participation:

SETUP_REQUIRE_PRODUCTION_STORAGE=true \
SETUP_PROOF_URL=https://your-app.example/api/command-wave/setup/proof \
npm run setup:verify

For offline verification, set SETUP_PROOF_PATH and SETUP_GITHUB_PAYLOADS_PATH.

Verify the first-loop launch audit:

LAUNCH_AUDIT_URL='https://your-app.example/api/command-wave/launch/audit?remote=1' npm run launch:audit

Verify the chat launch before inviting builders into discussion:

CHAT_LAUNCH_URL='https://your-app.example/api/command-wave/launch/chat?remote=1' npm run chat:launch

If NEXT_PUBLIC_APP_URL is set, npm run launch:audit reads $NEXT_PUBLIC_APP_URL/api/command-wave/launch/audit?remote=1. Set LAUNCH_AUDIT_REMOTE=0 only for local shape checks. Without an explicit path, URL, or app URL, npm run launch:audit uses the local dev app at http://localhost:5001 and runs a shape-only audit.

If NEXT_PUBLIC_APP_URL is set, npm run chat:launch reads $NEXT_PUBLIC_APP_URL/api/command-wave/launch/chat?remote=1. Set CHAT_LAUNCH_REMOTE=0 only for local shape checks. Without an explicit path, URL, or app URL, npm run chat:launch uses the local dev app at http://localhost:5001 and runs a shape-only chat launch check.

npm run chat:launch exits nonzero until the chat launch track is ready, includes daemon-observed group discussion evidence, and is generated with remote setup checks. The full npm run launch:audit command exits nonzero until the reviewed PR loop is also ready. For offline verification, set CHAT_LAUNCH_PATH or LAUNCH_AUDIT_PATH. The chat verifier prints chat blockers, open items, and a chat operator checklist. The full launch verifier prints the status draft, state hashes, blockers, open items, and an operator checklist. When it can resolve the command-wave state target, it also checks that the public state snapshot hash matches the launch audit evidence. When it can resolve the project index target, it checks that the active project list includes the launch project and has a valid hash. Set LAUNCH_AUDIT_STATE_URL or LAUNCH_AUDIT_PROJECT_INDEX_URL to override those targets during offline checks.

Against a running local dev server on the default port:

SMOKE_BASE_URL=http://localhost:5001 npm run smoke:app
WALLET_SMOKE_BASE_URL=http://localhost:5001 npm run smoke:wallet
npm run setup:verify
npm run chat:launch
npm run launch:audit

If Next is running on another port, set LOCAL_APP_URL to that app URL before setup:verify, chat:launch, or launch:audit. The smoke check should pass when the app is loading. The setup and launch commands still exit nonzero until production env, live 6529 mode, durable storage, daemon posting, and daemon-observed group discussion are configured. PR-loop readiness also needs a selected hook repo, GitHub PR adapter, guardian state, guardian workflow, and the required guardian check.

Expose the current project state to the guardian with:

COMMAND_WAVE_STATE_URL=https://your-app.example/api/command-wave/state

Local API

• GET /api/6529/waves/search?q=term: search 6529 waves by name.
• POST /api/6529/context/preview: preview fetched wave context with cap/source metadata.
• GET /api/6529/chat-post: public hashable capability check for direct chat posting. It does not expose bot credentials.
• POST /api/6529/chat-post: protected human-triggered chat posting when the bot wallet is configured. Posts are paced for each builder.
• POST /api/auth/wallet/challenge: create a short-lived EIP-712 wallet ownership challenge in an HttpOnly cookie.
• POST /api/auth/wallet/verify: verify the typed wallet signature and issue a 24-hour HttpOnly identity session.
• GET /api/auth/session: return the current wallet identity and its non-member permission state.
• DELETE /api/auth/session: clear the wallet identity session and pending challenge.
• POST /api/command-wave/chat/observe: protected daemon sync for visible project chat drops. It deduplicates posts and updates the public project state.
• GET /api/readiness: show local/production readiness checks.
• GET /api/command-wave/setup/proof: public setup proof with hashes and third-party verification targets.
• GET /api/command-wave/state: public current wave state snapshot for guardian PR checks.
• GET /api/command-wave/projects: public active hook project index with a stable project-list hash.
• GET /api/command-wave/reports/contribution: public informational contribution report with a reportHash.
• GET /api/command-wave/verification/manifest: public map of verification endpoints, chat posting capability, required hash fields, stable anchors, and its own manifest URL.
• GET /api/command-wave/launch/audit: public first-loop launch audit with authority boundary. Add ?remote=1 to run remote wave and repo setup checks.
• GET /api/command-wave/launch/chat: public chat launch audit with chatLaunchHash, including Group discussion evidence from daemon-observed messages. Add ?remote=1 before inviting builders into discussion.
• GET /api/command-wave: return the current local command wave.
• PUT /api/command-wave: disabled in phase 1. Use scoped setup, proposal, vote, decision, run, and review routes.
• PATCH /api/command-wave: update the demo wave/repo setup and log it.
• DELETE /api/command-wave: reset the local demo.
• POST /api/command-wave/proposals: submit a work proposal.
• POST /api/command-wave/votes: record a yes/no vote. Body requires proposalId, voterIdentity, and vote.
• POST /api/command-wave/decision: record a manual project decision link. Body requires proposalId and reference. PR commands require a decision URL from project chat.
• POST /api/command-wave/codex-packet: create a copyable manual Codex work packet for a PR command with a recorded project decision link.
• POST /api/command-wave/execute: prepare the target branch, commit the Codex work packet plus optional approved { path, content } files, and open a draft PR record.
• POST /api/command-wave/review: run the reviewer adapter, record a PR comment, create a check run, and save reviewer proof.

Command-wave mutation routes and chat posting are open only for local demo mode when ADMIN_API_KEY is blank. Once ADMIN_API_KEY is set, send it as either x-admin-api-key: <key> or Authorization: Bearer <key>. In production, missing ADMIN_API_KEY is a server misconfiguration and protected actions fail closed.

Wallet sessions authenticate public identity only. They do not authorize maintainer APIs. Protected setup, proposal, vote, run, and review routes still require the separate admin key until role-based maintainer authorization is built.

API errors include an errorId so a user-visible error can be matched to server logs. Routes that accept JSON require a JSON object body. Malformed JSON, arrays, and null bodies return 400-level errors.

Next Production Steps

1. Apply the Postgres schema, set COMMAND_WAVE_STORE=postgres, and verify durable storage.
2. Set the initial hook chat, keep the GitHub repo placeholder for chat launch, record daemon-observed group discussion, then run the remote chat launch audit until setup is reachable.
3. Add an isolated Codex worker that produces bounded patch files before the existing branch, commit, and draft PR sequence.
4. Add contract-aware review adapters for diffs, tests, deployment files, governance, parameters, and upgradeability patterns.
5. Add human-reviewed contribution reports across wave posts, PRs, reviews, commits, and ledger events.
6. Add GitHub identity, deterministic admission, database-backed session revocation, distributed rate limits, job queue controls, and required GitHub branch protection.