docs: add brownfield Memory Bank adaptation protocol

[dapi]

Problem

Brownfield repositories may not yet have an adapted memory-bank/. If an agent begins discovery after the generic template is copied or starts consulting it, template placeholders and generic rules can be mistaken for project facts.

The current brownfield section in docs/adoption.md describes inventory and filling order, but it does not provide an executable end-to-end protocol comparable to docs/greenfield-integration-protocol.md. It also needs an explicit boundary between pre-adaptation research and governed Memory Bank work.

Goal

Add a dedicated brownfield adaptation protocol for web services and CLI utilities, and link it from the adoption documentation. The protocol must help an agent capture the project as it actually works today, without inventing missing facts or treating the template as a source of project knowledge.

Proposed lifecycle

1. Pre-adaptation discovery (Memory Bank is not consulted). Read repository instructions and investigate only existing project sources: README/docs, source code, manifests, CI/CD, configuration, runbooks, historical ADRs, and other authoritative evidence.
2. Create an evidence-backed intake PRD outside memory-bank/. This temporary artifact records the current product problem, users/jobs, goals, non-goals, scope, success signals, risks, source references, confidence, conflicts, assumptions, and open questions. It must not include invented architecture or delivery plans.
3. Install and activate Memory Bank. Only after discovery, copy/init memory-bank/, then read its README, governance, and templates.
4. Adapt canonical owners from the same evidence. Populate product/, domain/, engineering/, and ops/; record unknown, conflicting, or owner-pending facts explicitly instead of guessing.
5. Govern the intake PRD. Convert/import it into memory-bank/prd/PRD-XXX-*.md, update README indexes and derived_from links. The governed PRD must depend only on already-adapted upstream owners.
6. Add only durable evidence-backed artifacts. Create use cases and historical ADRs only where the discovery sources support them. Do not create epics, feature packages, or delivery plans unless an existing project source explicitly requires them.
7. Validate and trial. Run memory-bank lint/memory-bank doctor (or state the verification gap) and use the adapted context on one real task before declaring the rollout complete.

Required discovery inventory

• Runtime modules, boundaries, dependencies, and critical code paths.
• API/UI contracts, clients, queues, scheduled jobs, webhooks, and external integrations.
• Configuration, feature flags, secret ownership/access process (never secret values), environments, CI/CD, releases/rollback, migrations, observability, SLOs, and alerts.
• Existing README/wiki/design docs/ADRs/runbooks, their owners, and known freshness concerns.
• Product terminology, key user/operational flows, current technical debt, risky areas, and unresolved ownership.

Each durable fact needs a canonical owner in Memory Bank. Conflicts and uncertainty need an explicit gap/open question with evidence and, where known, an owner.

Product-type considerations

The protocol should be conditional rather than force irrelevant documents. Mark unsupported dimensions as N/A with a short reason.

Web services

• API and UI contracts; authentication/authorization, tenancy, rate limits, compatibility commitments.
• Data stores, caches, asynchronous processing, webhooks, retention and migration constraints.
• Deployment/rollback, health checks, contract/E2E testing, observability and operational response.

CLI utilities

• Commands/subcommands, flags, stdin/stdout/stderr contract, exit codes, non-interactive behavior and shell completion.
• Installation/distribution, supported OS/architectures, update/uninstall behavior.
• Configuration files, environment variables, filesystem effects, remote API compatibility, golden tests and user-visible error compatibility.

Safety and migration rules

• Do not overwrite existing documentation, repository instructions, or runtime code as part of adaptation.
• Do not copy secrets, PII, tokens, or internal endpoints into Memory Bank; document ownership and access procedure only.
• Link to external/legacy sources instead of duplicating them indiscriminately; preserve their status and freshness caveats.
• Perform the adaptation in a reviewable change and list created, changed, and intentionally unadapted documents.
• Define follow-up triggers/owners for keeping Memory Bank current as source code and operations evolve.

Acceptance criteria

• A new brownfield protocol exists and is linked from README.md and/or docs/adoption.md.
• It explicitly prohibits consulting memory-bank/ during pre-adaptation discovery.
• It defines the location, required evidence fields, lifecycle, and governed conversion of the intake PRD.
• It covers the inventory and conditional adaptations required by web services and CLI utilities.
• It defines a minimum rollout DoD: adapted baseline owners, explicit known gaps, governed/draft PRD, one real-task trial, and lint/doctor result or a stated verification gap.
• It remains generic and does not introduce downstream project terminology or facts.
• Existing brownfield guidance is reconciled with the protocol; no contradiction with the greenfield protocol remains.
• Links and indexes are checked with memory-bank lint.

Nice to have

Include a copyable Codex prompt/command and a compact completion-evidence checklist, analogous to the greenfield protocol.

[dapi]

Feature package created for this issue: FT-53 brief, with the implementation plan.