# Spec: Your Agent Identity Cleanup
> **Purpose:** Builder-facing BrainDrive product/engineering spec for cleaning up the remaining BrainDrive+1 / `braindrive-plus-one` identity surfaces after the owner-facing rename to **Your Agent**.
> **Generated from:** Dave W request on 2026-07-01, prior rename brief, prior implementation plan, prior work log, and a focused scan of `/home/hex/Project/BrainDrive-Test-01` on `dev`.
## Overview
### What We're Building
BrainDrive needs a clear, durable identity contract for the root assistant now called **Your Agent**. The prior cleanup renamed owner-facing and model-visible display text from **BrainDrive+1** to **Your Agent**, while deliberately preserving the internal id `braindrive-plus-one`. This spec defines the next cleanup: decide and enforce where the legacy id may remain, where it must be replaced or centralized, how existing memory should migrate, and how tests should prevent the old naming from leaking back into owner-facing or model-fed surfaces.
This is not a blind global rename. `braindrive-plus-one` is currently a persisted project id, folder name, selection target, protected-project key, alias input, test fixture, and live-memory path. Removing it without migration can break existing owners, conversation state, root project protection, sidebar selection, update flows, and memory repair.
### Why It Matters
The product name the owner sees is **Your Agent**, but the repo still has many `braindrive-plus-one` references. Some are valid compatibility references; others are likely stale implementation detail. Without a written identity contract, future agents may either preserve too much legacy naming or attempt a breaking rename.
This cleanup should give builders one answer to three questions:
1. What is the canonical owner-facing name? **Your Agent**.
2. What is the canonical persisted root-agent id going forward? **Open decision; recommendation below.**
3. Where may `braindrive-plus-one` remain as a legacy compatibility alias? Only in documented migration, alias, historical, and test-compatibility surfaces.
### Target Audience And Stakeholders
| Audience | Role / Need |
|---|---|
| BrainDrive owners | See and hear **Your Agent**, never **BrainDrive+1** or raw `braindrive-plus-one`, in normal product use. |
| Dave J / implementation agent | Needs a precise cleanup boundary so migration is safe and not a broad destructive rename. |
| QA / harness agents | Need regression checks that separate allowed legacy compatibility references from owner-facing leaks. |
| Maintainers | Need centralized identity constants and migration behavior that future work can reason about. |
### Success Definition
When this work is complete, BrainDrive will:
1. Use **Your Agent** for every owner-facing and model-fed root-assistant name.
2. Have a documented canonical root-agent identity model, including whether the persisted id remains `braindrive-plus-one` or migrates to `your-agent`.
3. Contain no scattered legacy slug literals except in approved compatibility, migration, historical, or test fixtures.
4. Preserve existing owner memory, project manifests, conversations, and protected root-agent behavior.
5. Prevent new `BrainDrive+1`, `BD+1`, or unapproved `braindrive-plus-one` references from being introduced.
The work is not successful if:
1. Existing owner memory loses project files, conversation state, customizations, or root-agent protection.
2. The model can be fed **BrainDrive+1** or raw `braindrive-plus-one` as the current assistant/page name.
3. New installs create duplicate root-agent entries.
4. The cleanup removes the compatibility path before existing data has been migrated or safely redirected.
### Definition Of Done (V1)
When V1 is done, it can:
1. Explain the canonical identity contract in code and tests: display name, persisted id, folder path, aliases, and historical exceptions.
2. Repair or migrate an existing memory layout containing `braindrive-plus-one`, `your-agent`, or both without data loss.
3. Seed new memory layouts according to the accepted canonical id decision.
4. Keep **Your Agent** as the only owner-facing and model-fed name.
5. Prove, through focused tests and searches, that all remaining legacy references are intentional.
Explicitly not required for V1 unless approved:
- Removing historical `CHANGELOG.md` entries.
- Editing `your-memory.*` backup snapshots.
- Deleting owner-authored files without a migration/archive path.
- Changing unrelated page templates, provider configuration, auth, installer, or deployment behavior.
## Product Behavior
### User / System Experience
Owners should experience one root assistant named **Your Agent**. They should not need to know about `braindrive-plus-one`, legacy folders, project ids, template aliases, or migration behavior.
Internally, BrainDrive should treat the root assistant as a protected built-in surface. The implementation may keep legacy compatibility internally, but that compatibility must be invisible to normal owner-facing UI, prompts, messages, and generated artifacts.
### Primary Flows
1. **New install:** BrainDrive seeds one root assistant entry named **Your Agent** and opens it by default.
2. **Existing install with only `braindrive-plus-one`:** BrainDrive preserves the owner's root-agent data and either keeps the legacy id under a documented compatibility contract or migrates it to the canonical `your-agent` id.
3. **Existing install with both `braindrive-plus-one` and `your-agent`:** BrainDrive resolves the duplicate safely, preserving any conversation state or owner-authored files.
4. **Client selection:** Sidebar, collapsed sidebar, empty state, project hooks, and app shell select the root assistant through the canonical identity helper rather than raw scattered string literals.
5. **Model context:** Gateway, memory, prompts, and project context feed **Your Agent** as the display name.
### Secondary Flows
- If a legacy path is referenced by an existing conversation, tool call, memory link, or update flow, BrainDrive resolves it through compatibility handling instead of failing.
- If both legacy and canonical folders contain divergent owner-authored data, BrainDrive must preserve both and surface a deterministic migration result for review.
- If the system cannot safely merge duplicate folders, it must stop with a clear diagnostic instead of deleting data.
### UX / Trust Bar
- Owner-facing language is stable: **Your Agent**.
- Migration is invisible during normal use unless a manual review is required.
- Any manual review names the affected owner files and the recommended disposition.
- No prompt, welcome copy, settings tab, sidebar label, or generated page header says **BrainDrive+1**.
## User Stories
### US-1: Owner Sees One Name - **Confirmed**
As a BrainDrive owner, I want the root assistant to always be called **Your Agent** so that BrainDrive feels coherent and does not expose old product naming.
Details - source, steps, acceptance criteria
**Source:** Prior rename brief and work log.
**Steps:**
1. Owner opens BrainDrive.
2. Owner lands on the root assistant.
3. Owner reads the sidebar, empty state, settings, and assistant response.
4. BrainDrive consistently names the surface **Your Agent**.
**Acceptance Criteria:**
```gherkin
Given a new or existing memory layout
When the owner opens the root assistant
Then the UI labels the surface "Your Agent"
And no owner-facing text says "BrainDrive+1", "BD+1", or "braindrive-plus-one"
```
```gherkin
Given the model receives project context for the root assistant
When the assistant refers to the active page or assistant
Then the model-visible name is "Your Agent"
And the model is not fed "BrainDrive+1" as the project name
```
**Status:** Confirmed
### US-2: Existing Owner Data Is Preserved - **Open Pending Canonical Id Decision**
As an existing BrainDrive owner, I want my current Your Agent files and conversation state preserved so that cleanup does not erase my memory or break continuity.
Details - source, steps, acceptance criteria
**Source:** Repo scan showing live memory uses `documents/braindrive-plus-one/` and also contains an orphan `documents/your-agent/` folder.
**Acceptance Criteria:**
```gherkin
Given an existing memory layout with a `braindrive-plus-one` root project
When identity cleanup runs
Then root-agent files, conversation id, default skills, and owner-authored content are preserved
And the manifest contains exactly one active root-agent project unless a conflict requires manual review
```
```gherkin
Given both `documents/braindrive-plus-one/` and `documents/your-agent/` exist
When their contents differ
Then cleanup does not delete either folder silently
And it either performs a deterministic safe merge or reports a manual-review item
```
**Status:** Open
### US-3: New Installs Use The Canonical Identity - **Open Pending Canonical Id Decision**
As a new BrainDrive owner, I want the starter memory to create only the current Your Agent identity so I do not inherit legacy BrainDrive+1 internals.
Details - source, steps, acceptance criteria
**Source:** Prior rename plan plus current `memory/init.ts`, `projects.seed.json`, and gateway root project defaults.
**Acceptance Criteria:**
```gherkin
Given an empty memory root
When BrainDrive initializes memory
Then it creates exactly one protected root assistant project named "Your Agent"
And the created id/folder follows the accepted canonical id decision
And no duplicate `your-agent` / `braindrive-plus-one` project appears in the manifest
```
**Status:** Open
### US-4: Maintainers Have One Identity Contract - **Confirmed**
As a maintainer, I want root-agent ids, aliases, display names, and protected-project checks centralized so future changes do not require hunting scattered literals.
Details - source, steps, acceptance criteria
**Source:** Focused tracked-file scan on 2026-07-01 found `braindrive-plus-one` in gateway, memory init, update prompting, client layout, hooks, empty state, tests, starter seeds, and architecture lint.
**Acceptance Criteria:**
```gherkin
Given a developer needs to identify the root assistant
When they inspect the code
Then there is a single documented root-agent identity module or equivalent constant surface
And raw `braindrive-plus-one` literals are limited to that module, migration fixtures, historical docs, and explicit compatibility tests
```
**Status:** Confirmed
### US-5: QA Can Prove Legacy References Are Intentional - **Confirmed**
As QA, I want automated checks that distinguish approved legacy compatibility references from owner-facing leaks so cleanup stays clean after future work.
Details - source, steps, acceptance criteria
**Acceptance Criteria:**
```gherkin
Given the repo contains legacy compatibility code
When the retired-name scan runs
Then every remaining `BrainDrive+1`, `BD+1`, or `braindrive-plus-one` match is either allowlisted with a reason or fails verification
```
```gherkin
Given a test fixture uses legacy `braindrive-plus-one`
When the test runs
Then it verifies migration or compatibility behavior
And does not normalize legacy naming into owner-facing output
```
**Status:** Confirmed
## Requirements
### Functional Requirements
- [ ] The canonical owner-facing display name must be **Your Agent**.
- [ ] The system must define one canonical root-agent identity contract covering display name, persisted id, folder path, aliases, and protected-project behavior.
- [ ] If the canonical persisted id changes to `your-agent`, existing `braindrive-plus-one` memory must be migrated or redirected with no data loss.
- [ ] If the canonical persisted id remains `braindrive-plus-one`, the codebase must still reduce scattered raw literals by centralizing the compatibility name and documenting why it remains.
- [ ] New installs must seed exactly one root-agent project.
- [ ] Existing installs must repair duplicate root-agent entries deterministically.
- [ ] Owner-facing and model-fed surfaces must never use **BrainDrive+1**, `BD+1`, or raw `braindrive-plus-one` as display text.
- [ ] Compatibility handling must preserve historical conversations and file links that reference the legacy path.
- [ ] Stale live-memory root-agent `spec.md`, `plan.md`, `run-interview.md`, and `run-planning.md` must not be deleted unless the migration rules explicitly preserve or archive owner-authored content.
### AI / Model / Tool Behavior
- [ ] Model context must identify the active root assistant as **Your Agent**.
- [ ] Memory tools must resolve root-agent reads/writes consistently after migration or alias resolution.
- [ ] If a tool receives a legacy `documents/braindrive-plus-one/...` path after canonicalization, expected behavior must be defined: redirect, alias, or fail with migration guidance.
- [ ] Generated owner-facing text must not repeat the legacy display name.
### Data, Memory, And Artifact Contracts
| Data / Artifact | Current State | Target Contract | Migration / Retention |
|---|---|---|---|
| Project display name | `Your Agent` in current defaults and live manifest | Always `Your Agent` | Preserve and regression-test. |
| Project id | `braindrive-plus-one` in gateway, memory, client selection, tests | Open: keep as legacy id or migrate canonical id to `your-agent` | Recommendation: migrate canonical id to `your-agent` only with compatibility alias and one release cycle of redirect support. |
| Root-agent folder | Live memory has `documents/braindrive-plus-one/`; also has `documents/your-agent/` | One active canonical folder | Preserve both if divergent; remove/archive only after conflict review. |
| Starter template | Template folder is `projects/templates/your-agent/AGENT.md`; no `spec.md`/`plan.md` | Your Agent should not behave like a normal page template unless decision changes | Recommendation: keep root assistant as special protected surface, not a normal page. |
| Historical docs | `CHANGELOG.md` and backups may contain old terms | Historical references may remain | Exclude from product cleanup; do not rewrite history. |
| Tests | Many fixtures assert legacy id behavior | Tests must express migration/compatibility intent | Rename vague tests; keep legacy fixtures only for compatibility coverage. |
### Interface / UX Requirements
- [ ] Sidebar and collapsed sidebar show **Your Agent**.
- [ ] Empty state copy may say "Welcome to BrainDrive" but must not say **BrainDrive+1** or expose the slug.
- [ ] Settings tabs and customization surfaces use **Your Agent**.
- [ ] Any conflict or migration diagnostic uses owner-safe language and file names only where needed.
### Observability / Evidence Requirements
- [ ] A retired-name scan must list remaining legacy references and their approved category.
- [ ] Migration tests must cover new memory, existing legacy memory, duplicate legacy/canonical memory, and conversation-state preservation.
- [ ] File-level evidence must show the manifest and root-agent files after migration.
- [ ] If live app verification is possible, an owner-facing assistant message must refer to **Your Agent** and not **BrainDrive+1**.
## Scope
### Work Type
- [x] **V1** - First safe cleanup with explicit migration contract.
- [x] **Documentation/specification** - Defines source-of-truth identity behavior.
- [x] **BrainDrive core/foundation** - Root assistant identity, memory init, gateway, client selection, tests.
### Included
- Root-agent identity contract.
- New-install seeding behavior.
- Existing-memory repair or migration behavior.
- Duplicate `braindrive-plus-one` / `your-agent` handling.
- Owner-facing and model-fed retired-name protection.
- Centralization of raw root-agent ids and aliases.
- Focused tests and retired-name scans.
### Explicitly Excluded
- Provider/model configuration cleanup.
- Auth, billing, deployment, or installer changes unless directly required by identity migration.
- Broad UI redesign.
- Historical changelog rewriting.
- Backup snapshot rewriting.
- Deleting owner-authored files without explicit migration/archive behavior.
### Future Versions / Deepenings
- Remove legacy alias support after a defined compatibility window and migration telemetry/evidence.
- Add a structured memory migration report visible to maintainers.
- Add a repo lint rule that blocks unapproved root-agent legacy literals outside the identity module and tests.
## Invariants And Edge Cases
### Properties That Must Always Hold
- [ ] Exactly one active root assistant appears in the project manifest after initialization/repair unless manual conflict review is required.
- [ ] The active root assistant display name is **Your Agent**.
- [ ] The root assistant remains protected from owner deletion/rename if that protection exists today.
- [ ] Owner-authored files and conversation ids are not lost during migration.
- [ ] Legacy names are never model-fed as the current assistant display name.
- [ ] Historical backups remain untouched unless a separate backup-migration decision is approved.
### Edge Cases To Test
- [ ] Empty memory root.
- [ ] Manifest contains only `braindrive-plus-one`.
- [ ] Manifest contains only `your-agent`.
- [ ] Manifest contains both ids and neither has conversation state.
- [ ] Manifest contains both ids and one has conversation state.
- [ ] Manifest contains both ids and both have conversation state.
- [ ] Folder exists without manifest entry.
- [ ] Manifest entry exists without folder.
- [ ] Folder contents are identical.
- [ ] Folder contents differ.
- [ ] Existing conversations reference `documents/braindrive-plus-one/...`.
- [ ] Existing tests or fixtures intentionally include legacy ids.
- [ ] Retired display names appear only in historical files.
### Failure Modes
| Scenario | Expected Behavior |
|---|---|
| Duplicate root-agent entries cannot be merged safely | Preserve both, avoid destructive writes, report manual review item. |
| Legacy path is referenced after canonical migration | Resolve through alias/redirect or fail with a clear compatibility diagnostic. |
| Migration writes manifest but file move fails | Roll back or leave old manifest intact; do not orphan owner data. |
| Retired display name appears in model context | Verification fails. |
| Retired slug appears outside approved compatibility zones | Verification fails until moved, centralized, or allowlisted with reason. |
## Technical Context
### Existing System Context
- Prior rename PR #203 changed model-visible/default display names to **Your Agent** and preserved `braindrive-plus-one`.
- Current tracked references include:
- `builds/typescript/gateway/projects.ts` root project id.
- `builds/typescript/memory/init.ts` protected ids, template alias, fallback seed, repair logic.
- `builds/typescript/memory/starter-pack/projects/projects.seed.json` seed id.
- `builds/typescript/memory/update-prompting.ts` template manifest exclusion.
- `builds/typescript/client_web/src/components/layout/*` sidebar/root selection logic.
- `builds/typescript/client_web/src/hooks/useProjects.ts` default/root selection logic.
- `builds/typescript/client_web/src/components/chat/EmptyState.tsx` root intro key.
- Focused tests in gateway, memory, hooks, and layout.
- `builds/typescript/tools/architecture-lint/draft3-memory-lint.ts` starter-pack guard.
- Current live memory has `documents/projects.json` with `id: "braindrive-plus-one"` and `name: "Your Agent"`.
- Current live memory also contains both `documents/braindrive-plus-one/` and `documents/your-agent/`.
- The starter template `projects/templates/your-agent/AGENT.md` says Your Agent does not maintain its own `spec.md`, `plan.md`, interview procedure, or planning procedure.
### Integration Points
- Gateway project service and protected root project.
- Memory initialization, repair, template aliasing, and starter-pack seeding.
- Memory update prompting and starter-pack manifest generation.
- Client project selection, sidebar rendering, collapsed sidebar, empty state, and hooks.
- Project file paths, memory tools, and conversation history references.
- Architecture lint and focused regression tests.
### Hard Constraints
- Do not put BrainDrive-owned provider keys in client config.
- Do not remove Ollama or BYOK OpenRouter provider choices.
- Do not modify auth/authorization behavior as part of this cleanup.
- Do not rewrite historical backups or snapshots.
- Do not make destructive memory changes without preserving owner data.
- Use `dev` as the normal base branch for this repo unless a release decision says otherwise.
### Build Workflow Inputs
- Candidate implementation approach: create a root-agent identity helper/module that exports canonical display name, canonical id, legacy ids, path aliases, and predicate helpers.
- Candidate migration approach: migrate active root-agent id/folder to `your-agent` for new installs and existing layouts, with `braindrive-plus-one` retained as a legacy alias for reads/repairs.
- Candidate minimal approach: keep persisted id `braindrive-plus-one`, but centralize and document it as a compatibility id. This is lower risk but leaves the old slug as the active id.
- Current-state cleanup item: live memory duplicate folder handling needs explicit conflict policy before deletion.
## Test Strategy
### Test Levels Required
- [x] **Unit** - Identity helper, slug predicates, alias resolution.
- [x] **Integration** - Memory init/repair, gateway project list, scaffold behavior.
- [x] **E2E / workflow** - Startup lands on Your Agent and can select/send a root-agent chat.
- [x] **Regression** - Existing Your Agent, sidebar, project hooks, update flows, and protected-project behavior.
- [x] **Human review** - Confirm remaining legacy references are approved and owner-facing language is clean.
### Verification Approach
- **Agent self-verification:** Run focused retired-name scans before and after implementation.
- **Automated verification:** Run focused tests for memory init, gateway projects, AppShell/sidebar, hooks, and any new migration helper.
- **Human verification:** Review migration conflict reports and confirm the remaining references are either historical or compatibility-only.
- **Runtime verification:** When provider config is available, ask the running app what page/context it is using and confirm it says **Your Agent**.
### Acceptance Evidence
- [ ] Test output for focused backend and web slices.
- [ ] Retired-name scan with allowlist categories.
- [ ] Before/after manifest examples for legacy-only, canonical-only, and duplicate layouts.
- [ ] Confirmation that live `projects.json` and root-agent docs no longer expose retired display names.
- [ ] Runtime owner-facing message screenshot/log if available.
### Baseline / Regression Impact
- Always-run candidates:
- `cd builds/typescript && npm run test -- --run memory/init.test.ts gateway/projects.test.ts`
- `cd builds/typescript && npm run web:test -- --run src/components/layout/AppShell.test.tsx src/hooks/useProjects.test.ts`
- `cd builds/typescript && npm run build`
- `cd builds/typescript && npm run web:typecheck`
- Broader checks:
- `cd builds/typescript && npm run web:test`
- `cd builds/typescript && npm run test`
- Known risk: full `npm run test` previously failed on Draft 3 starter-pack lint issues around missing Your Agent template artifacts. This cleanup may either resolve or intentionally preserve that failure depending on the accepted Your Agent artifact decision.
## Security, Privacy, And Trust Considerations
### Risk Level
- [x] **Medium** - Touches owner memory files, manifests, conversation continuity, model context, and file paths.
### Threat / Trust Assessment
- **User input:** No new owner input surface is required, but owner-authored memory must be preserved.
- **Code execution:** No new code execution surface.
- **Data sensitivity:** Memory files and conversations may contain personal owner data.
- **Network surface:** No new network API required unless migration status is exposed through existing gateway routes.
- **Model/tool behavior:** Incorrect migration can feed stale context or wrong project identity to the model.
- **Blast radius:** Root assistant startup, routing, and all owners' first page can be affected.
- **Owner trust:** The owner should never see data loss or old branding caused by cleanup.
### Required Mitigations
- [ ] Treat memory migration as data migration, not text replacement.
- [ ] Preserve backups/snapshots.
- [ ] Fail closed on unsafe duplicate-folder merges.
- [ ] Add tests for data-preserving duplicate resolution.
- [ ] Keep compatibility alias support until explicit removal is approved.
## Explicit Boundaries
### Do Not Modify
- [ ] `CHANGELOG.md` historical entries unless a separate docs decision approves it.
- [ ] `builds/typescript/your-memory.*` backup/snapshot directories.
- [ ] Provider secrets, owner keys, gateway URLs, auth, installer, or deployment assets outside the direct identity path.
### Do Not Introduce
- [ ] A second visible root assistant.
- [ ] A normal page template for the protected root assistant unless the product decision changes.
- [ ] Silent deletion of `documents/braindrive-plus-one/` or `documents/your-agent/`.
- [ ] Client-only label overrides as the sole source of truth for model-visible identity.
### Security / Trust Boundaries
- [ ] Never commit secrets or credentials.
- [ ] Never modify authentication/authorization without explicit approval.
- [ ] Never delete owner memory without an archive, merge, or explicit approval path.
## Open Questions
1. **Should the canonical persisted root-agent id become `your-agent`, or should `braindrive-plus-one` remain the stable internal id?**
**Recommendation:** Move toward `your-agent` as the canonical id for new installs and active memory, but only with `braindrive-plus-one` retained as a legacy alias/redirect through at least one compatibility window. This best matches the product rename and reduces long-term confusion, but it is higher risk than display-name cleanup.
2. **Should the live `documents/your-agent/` folder be deleted, merged, or archived when the manifest only points at `braindrive-plus-one`?**
**Recommendation:** Do not delete blindly. Compare files; if identical or known generated defaults, archive/remove according to migration rules. If divergent or owner-authored, preserve and create a manual-review report.
3. **Should Your Agent maintain `spec.md`, `plan.md`, `run-interview.md`, and `run-planning.md` at all?**
**Recommendation:** Keep the starter-pack rule: Your Agent is not a normal life-area page and should not maintain its own planning artifacts. Existing files should be preserved as legacy owner data or migrated into profile/page-level artifacts only with a separate content-placement decision.
4. **Should `braindrive-plus-one` be allowed in tests after cleanup?**
**Recommendation:** Yes, but only in tests that prove legacy migration/compatibility. Tests for normal new-install behavior should use the accepted canonical id.
5. **Should historical snapshots be rewritten to remove BrainDrive+1?**
**Recommendation:** No. Treat backups, old conversations, and changelog entries as historical records. Exclude them from product cleanup scans or allowlist them as historical.
6. **Should cleanup include a lint guard for new legacy literals?**
**Recommendation:** Yes. Add a focused guard that fails new owner-facing `BrainDrive+1`/`BD+1` references and unapproved raw `braindrive-plus-one` literals outside the identity module, migration code, historical docs, and compatibility tests.
## Recommendations
1. Approve a staged migration, not a global rename.
2. Make **Your Agent** the only display/model-facing name immediately.
3. Prefer `your-agent` as the future canonical persisted id, but keep `braindrive-plus-one` as a legacy alias until migration evidence proves it is safe to remove.
4. Centralize root-agent identity constants before touching call sites.
5. Write migration tests before changing seed/repair behavior.
6. Preserve and review duplicate live-memory folders before deletion.
7. Keep backup snapshots and changelog history untouched.
## Changelog
| Date | Change | Reason | Source | Decision |
|---|---|---|---|---|
| 2026-07-01 | Initial spec created | Define safe cleanup contract for remaining `braindrive-plus-one` identity surfaces | Dave W request + prior rename docs + repo scan | Open |
## Conversation References
| Date | Source | Topics Discussed | Link |
|---|---|---|---|
| 2026-06-30 | `dave-j-your-agent-rename-brief.md` | Display rename from BrainDrive+1 to Your Agent; preserve internal id in prior scope | `/home/hex/Reference/Designs/BrainDrive-MVP/BrainDrive - Your Agent/dave-j-your-agent-rename-brief.md` |
| 2026-06-30 | `dave-j-your-agent-rename-implementation-plan.md` | Completed display-name implementation plan and open questions | `/home/hex/Reference/Designs/BrainDrive-MVP/BrainDrive - Your Agent/dave-j-your-agent-rename-implementation-plan.md` |
| 2026-06-30 | `dave-j-your-agent-rename-work-log.md` | Work log for PR #203 and known verification gaps | `/home/hex/Reference/Designs/BrainDrive-MVP/BrainDrive - Your Agent/dave-j-your-agent-rename-work-log.md` |
| 2026-07-01 | Current Codex session | Need spec for broader `braindrive-plus-one` cleanup | Current chat |
## Approval
- [ ] Reviewed by: _______________
- [ ] Date: _______________
- [ ] Ready for Planning: [ ]
---
*Next: Review and accept the canonical id decision, then create a test plan before producing the implementation plan.*