# Working on Brook

Authoring custody: the canonical `support-brook` repository is generated
publication output. First-party changes currently belong in the `support` family
repository at `editions/brook/` or the selected shared source named by its
composition. These instructions are exported as `AGENTS.md`. An owner or
community fork is editable source under that author's control; it is outside
the canonical publisher's destinations. Confirm which checkout you are using
before editing. CI publishes into fresh clones and refuses dirty or
provenance-divergent targets; it does not overwrite your local working checkout.

The shared product is a cohesive starting point. Owners and community authors
may change core behavior, schema, UI, infrastructure and any other source.
Configuration and hooks are useful conveniences, not limits. Agents choose the
integration method and handle complex merges; verify recorded requirements and
affected data transitions. Useful discoveries can be contributed with tests to
shared source, then deliberately adopted and verified by other editions.

This is your self-contained Support Brook edition. Read `IMPLEMENTATION.md`, `CONTRACT.md`, `HANDOVER.md`, `docs/SETUP.md` and `composition.lock.json` before changing behavior or deploying. The contract retains the full release target; it is not an assertion every clause is implemented.

Use Node26.8.1 and pnpm10.12.4. Run `pnpm verify` for the implemented surface. Inspect provider-facing acceptance separately; never infer a real refund or delivered email from a mocked transport, a green build or provider acceptance alone.

The app uses TanStack Start documents in one Cloudflare Worker, Hono APIs and D1. Native sessions guard operator routes and every read/write API. Keep all provider secrets server-side. D1 owns immutable approved decisions and durable command identities. A submitted refund cannot be edited or cancelled; ambiguous outcomes reconcile using reads and never resend. Customer success replies require confirmed provider action, and optional resolution requires mail-provider acceptance. Preserve these boundaries and all recorded owner intent during updates.

No application mocks or silent provider fallbacks. Missing configuration must fail honestly. Fixtures belong only in tests. Prefer small responsibility-focused files. Remove superseded code. Owners and their agents may edit any source in this fork; use ordinary Git integration to preserve every customization, then verify applicable guarantees and recorded intent. A clean merge or passing upstream suite alone is insufficient.

`src/family/support` and `src/modules` are composed source, not remote runtime dependencies. Your fork contains the complete application. `docs/source-seed-requirements.json` and `docs/SOURCE-LINEAGE.md` retain prior requirements and provenance. Do not expose private messages, raw intake records, credentials or session tokens in screenshots, logs or public artifacts.