git:20261013.a003abb to git:20261013.f565165

15 added, 14 removed. Audit A to A.

# Bamboo Agent Guidance

Read [README.md](./README.md) for the product boundary. Use this canonical Jiandu memory contract:

- 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](./gitflow.md). Give each

- bounded Issue one owner, branch and isolated worktree. Related feature PRs feed

- one finite `integration/<batch>`; only its named integrator writes that branch

- and submits the combined candidate to `dev`. Freeze before full validation;

- queue admissions and do not separately merge already-included slices into

- `dev`. Keep scoped evidence separate from exact-head/base acceptance. Assign

- one release owner and one writer for each build output; do not cancel or clean

- another worker's resources. Existing review and protection gates still apply.

- CI deduplication requires the control-PR rollout in that document; these rules do

- not remove existing checks or excuse real failures.

+ Follow [Parallel Development](./gitflow.md). Give each bounded Issue one owner,

+ branch and isolated worktree; only the named integrator writes a shared batch

+ branch. Dev admission uses required fast checks and current review; heavy

+ compilation and full tests are advisory for dev, with failures owned and tracked.

+ Freeze a recorded batch for complete release acceptance; `release → main` must

+ pass the full required suite and platform matrix. Keep one release owner and one

+ writer per build output. Preserve exact-source evidence and never cancel or

+ clean another worker's resources. The new gate roles require verified workflow

+ and separately approved protection configuration; never bypass current gates.

+ Use the authoritative [Release Process](./CONTRIBUTING.md#release-process) for

+ frozen cuts, repairs and publication.

## Pull Request Review

### Bamboo #791 integration exception

For the #791 multi-agent epic, the user's 2026-09-28 delivery instruction takes

precedence over the per-Issue PR and review steps below. Inventory all related

PR heads and existing work first, then merge implemented work into one local

integration baseline. Review integration changes locally and use focused checks

- while assembling it. Run the complete affected regression once after the

- baseline is ready, then submit one PR to `dev` and satisfy its required GitHub

- checks. Do not request or wait for GitHub Codex PR review for this epic. Close

- superseded component PRs and clean only safely merged worktrees after the final

+ while assembling it. Submit one PR to `dev` through its required fast GitHub

+ checks under the current gate policy. Run the complete affected regression once

+ on the frozen release snapshot before promotion to `main`. Do not request or

+ wait for GitHub Codex PR review for this epic. Close superseded component PRs and clean only safely merged worktrees after the final

integration is accepted. Preserve dirty or uncertain worktrees.

- Every non-draft pull request that enters review must have a Codex review for

its current head and base. If no current review is already running or complete,

add a pull-request comment whose entire body is `@codex review`; do not rely

only on automatic review triggering.

- Wait for the `Codex Review Summary` to finish. A 👍 reaction on the trigger or

an explicit Codex zero-findings result confirms a clean run; a `Completed`

summary alone only confirms that the run ended. Review suggestions or inline

comments are findings that must be resolved. Inspect the summary, review body,

reactions, and unresolved threads instead of treating an empty

`reviewDecision` or a `COMMENTED` review as approval.

- Any head commit or base change invalidates the earlier Codex result. After the

update, resolve applicable findings and trigger a fresh exact-head review.

- Green CI does not mean review passed. Add `review:agent` and remove

`review:needed` only after the current-head Codex review has finished with no

unresolved findings and the remaining acceptance and merge gates pass.