Garden Development Resource

Garden Development Resource

Garden can serve the Oros Governance project as an elastic research, design, implementation, and review team. Given a bounded issue, it can study relevant work, draft a design PR, implement an approved design on a bot fork, test and review the result, fix findings, and present it for human approval.

This fits the project's story-driven plan: people choose stakeholder outcomes and acceptance tests; Garden supplies sustained engineering effort. It is especially useful for turning the milestones into working slices such as Sprint 0 CONTRIB attribution, persistence, M1 escrow, and later delegation and audit features.

Best uses

• Turn stories into scoped designs with authority boundaries, dependencies, and tests.
• Implement approved slices in forks of dckc/vattr97, Endo, or Agoric repositories.
• Add tests, run adversarial review panels, and fix must-fix findings.
• Research uncertain dependencies such as ERTP ledger façades, Horton audit, OpenCollective, and deployment options.
• Rebase, shepherd, and report on PRs through review.

Garden's operating model is compatible with the project's object-capability architecture: routine work uses a bot identity and forks; carrying approved work upstream under a maintainer's identity requires a separately authorized ferry. Application code still needs explicit capability review.

Contributing a host

The project can contribute a host and its inference capacity to Garden's shared resource pool. vattr97 issue #17 tracks that contribution; Garden's turnkey-host issue #44 documents the current onboarding path. Credentials must remain host-specific and revocable: inference credentials belong to the host contributor, while Garden access uses a short-lived, repository-scoped bot credential delivered separately from the host image and configuration.

How to use it

1. File a bounded issue on kriskowal/garden with the target repository, story, acceptance tests, constraints, and exclusions.
2. Request a design first when authority, persistence, value flow, or cross-package APIs remain unsettled.
3. Approve the design, then request a build and the full gauntlet: tests, review panel, and fixer rounds.
4. Review the PR and upstream it only when the human acceptance criterion is met.

The resulting designs, PRs, tests, elapsed work, and blockers also provide evidence for project estimates. Garden's own cost accounting is still evolving, so human calibration remains necessary.

Evidence

• OpenCollective–ERTP integration converged, through maintainer correction, on an off-chain ERTP façade over OpenCollective and produced a reviewable vattr97 design PR. It remains a design, not an implementation.
• x402 escrow exchange produced an ocap-shaped Endo connector; its PR was approved and merged into the bot-oriented Endo fork.
• Portfolio-contract guards produced an open PR that passed a 16-seat panel. Portfolio delegation shows the fix loop: the panel found an atomicity error and missing failure test; a fixer addressed both. Its prototype PR is closed without merge.
• The DarkWow studies (#38, #39, #40, #41) demonstrate technical due diligence: Garden separated ordinary type hygiene from formal verification, exposed a misleading Lean build, reproduced a node failure, and qualified economic claims.

Boundaries

Garden is a supervised resource, not the project owner. People must set priorities, define acceptance, decide governance and monetary policy, authorize private access or real-money actions, and approve upstream changes.

Its README describes current operation; the design index also contains proposals. Every deliverable should state its actual status: designed, built, locally tested, CI-tested, reviewed, merged to a fork, or accepted upstream.