24 lines
1.3 KiB
Markdown
24 lines
1.3 KiB
Markdown
# Upstream Brand Neutralization Design
|
|
|
|
## Goal
|
|
|
|
Remove the upstream product name from the current Memory Gateway working tree while preserving the upstream HTTP protocol and application behavior.
|
|
|
|
## Scope
|
|
|
|
- Rename the upstream client module, class, configuration fields, environment variables, state attributes, response fields, tests, and integration test file to neutral `backend` terminology.
|
|
- Rewrite README, Skill documentation, examples, package metadata, and test records to describe an "upstream memory service".
|
|
- Remove the upstream-specific environment example because its variable names identify the product.
|
|
- Preserve `/api/v1/memory/add`, `/api/v1/memory/flush`, and `/api/v1/memory/search` paths.
|
|
- Do not rewrite Git history.
|
|
|
|
## Compatibility
|
|
|
|
This is an intentional configuration and response-schema rename. Deployments must move to `MEMORY_GATEWAY_BACKEND_*` variables, and health/add/flush consumers must read the `backend` field. No legacy aliases are retained because they would defeat the neutralization requirement.
|
|
|
|
## Verification
|
|
|
|
- Add an automated repository scan that rejects the forbidden upstream token in current files and file names.
|
|
- Run the full unit suite and compilation checks.
|
|
- Run a final case-insensitive repository scan excluding `.git`, virtual environments, runtime data, and generated bytecode.
|