Bamboo-agent: Instructions file for Codex

Bamboo Agent Guidance

Read README.md for the product boundary. Use this canonical Jiandu memory contract:

Before CI or release work, read the complete local shared delivery workflow, Actions ownership audit and Bamboo commands and test map. Every agent follows the same feature/dev/release/main workflow. The shared review documents include historical snapshots; use the local guide and actual workflow files for the current implementation and rollout status.

• Session memory is continuity for the current session. Project memory holds durable project facts and decisions; Global memory holds cross-project user context.
• Recall with a short lexical query. Use Jiandu's compact default top three id/summary results, then get only the selected item that needs full context.
• Query before writing. Store one confirmed atomic fact with a specific title and a few useful keywords, entities, and tags.
• Treat canonical Project memory as trusted durable project authority, but verify live repository or runtime state before acting. Treat Dream as a low-trust derived orientation snapshot, never as canonical evidence.
• Never store secrets or tokens. Do not add embeddings, vectors, or a duplicate Bamboo persistence/index layer.

Jiandu owns canonical persistence, derived indexes, lexical recall, and Dream snapshot bytes. Bamboo owns prompt selection and budget, optional reranking, and the model and cadence used to refresh Dream.

Parallel Development

Follow Parallel Development. Give each bounded Issue one owner, branch and isolated worktree; only the named integrator writes a shared batch branch. Every feature PR to dev must pass required Test, which aggregates Unit, E2E and the live SSH fixture on its actual merge source. Linux Cargo tests run in independently rerunnable shards, each owning its target directory and preserving independent default package configurations. Cargo runs each package's library/binary, integration and documentation cases once. Explicit feature owners run only their catalogued additional cases; new feature-sensitive cases require ownership review. Compatible configurations reuse compiled artifacts, with features/profile and actual Cargo freshness recorded. The ignored SSH case reuses its compiled executable. Unit/E2E are logical target groups. All agents add ordinary cases to that Cargo target catalog, instead of creating another Linux workflow for a covered case subset. CI policy rejects unregistered Rust test producers; native OS, containment-boundary, explicit manual diagnostics and pinned legacy routes are scoped exceptions with named owners. Native-platform tests remain available by manual dispatch. Fix failures in the feature branch before merging; record exact source, commands and results. Ubuntu Quick Checks owns the 46 Supervisor component/protocol registrations and 15 frontend artifact/policy registrations once. Each native feature job runs only the nine OS behavior cases selected by scripts/run-native-node-tests.cjs, which requires every selected name to actually pass. Retain Windows unsupported process-binding assertions and macOS's real process/listener checks; portable policies run only in Quick. The Browser Runtime Unit and E2E feature job owns all browser-runtime Node test files on Node 24; both feature aggregates require it to pass. Do not add a second automatic owner for those tests. Keep the standalone default storage authority families' serial selection in its owning shard, reusing its compiled library-test executable without repeating cases. Planner's 12 Plan and 10 artifact library cases are excluded from the ordinary parallel harness and run once serially using each package's same compiled canonical test executable. Preserve each default dependency graph and fail the existing feature gate on a missing, repeated or failed case. The independent Delegated Planner workflow retains its distinct API-only real CLI and original Clippy configurations; it does not repeat these library cases. Quick Checks remains auxiliary and never substitutes for runtime tests. For root and docs Markdown-only PRs, run Quick Checks and skip product tests; Markdown under source packages may be compiled into the application and must run the code path. A documentation-only check cannot serve as release test proof.