diff --git a/specs/contextcake-project-profiles/adversarial-review.md b/specs/contextcake-project-profiles/adversarial-review.md
new file mode 100644
index 0000000..5540ad6
--- /dev/null
+++ b/specs/contextcake-project-profiles/adversarial-review.md
@@ -0,0 +1,159 @@
+# ContextCake Project Profiles — Adversarial Review Record
+
+**Date:** 2026-07-28
+**Artifacts reviewed:** `spec.md`, `design.md`
+**Method:** independent read-only critic plus primary-agent red-team pass
+**Review posture:** poke holes first; prioritize isolation, migration, privacy,
+write safety, backward compatibility, and testability
+**Outcome:** all seven blocking findings were accepted and incorporated into the
+planning artifacts; implementation evidence does not exist yet
+
+---
+
+## 1. Blocking Findings and Resolutions
+
+### B1. Synced incomplete profiles could invalidate healthy local use
+
+**Finding:** Account sync currently reconstructs profile layers after scrubbing
+machine-local paths and commands. The draft simultaneously allowed these
+incomplete shells and required whole-manifest validation before any source
+opened.
+
+**Impact:** Pulling settings on a new Mac could make the complete manifest
+unusable, including a healthy local default profile.
+
+**Resolution:** Accepted. Canonical profiles now have explicit
+`pendingSources[]`. Incomplete or untrusted synced descriptors are structurally
+valid repair tasks but are never passed to adapters, selection, MCP, sync, or
+live-layer discovery. Migration and tests cover a healthy local profile beside
+an incomplete remote shell.
+
+### B2. Synced `activeProfile` could remotely activate local executable sources
+
+**Finding:** `activeProfile` is currently syncable. Merge-by-source identity can
+preserve a local MCP command underneath remotely scrubbed metadata.
+
+**Impact:** A remote snapshot, account switch, or id collision could select a
+local profile and spawn its MCP command without fresh local intent.
+
+**Resolution:** Accepted. The active app profile is now local-only. Executable
+source trust is a non-synced, machine-local digest bound to profile id, source
+identity, command, arguments, and optional account owner. Copies, remote shells,
+config changes, and account changes require confirmation again.
+
+### B3. Shipped hybrid manifests had no upgrade path
+
+**Finding:** The first draft rejected any document with both top-level `layers`
+and `profiles`, but current Pack/settings-sync behavior can already produce and
+test that transitional shape.
+
+**Impact:** A supported current configuration could fail on upgrade and strand
+Pack assignments, pending sources, or synced metadata.
+
+**Resolution:** Accepted. The selector recognizes a transitional hybrid mode and
+continues current flat-stack behavior until deliberate normalization. The atomic
+migration preserves named profiles, owner metadata, pending sources, runnable
+local fields, and Pack assignments. Real current-version manifests join the
+upgrade fixture corpus.
+
+### B4. Profile/revision identity covered only part of the Console load
+
+**Finding:** The Console loads graph and resolved concepts through separate
+requests. Adding profile identity only to `/api/graph` still permits mixed
+generations, and mutations targeting the merely “active” profile can race a
+switch.
+
+**Impact:** The UI could display topology from one profile with content from
+another or mutate the wrong stack.
+
+**Resolution:** Accepted. Every profile-derived response carries
+`{profileId, manifestRevision}`. Multi-request loads commit only when every
+response matches the expected pair. Every profile/source/Pack/mapping mutation
+names a profile and supplies a revision precondition; stale operations return
+409.
+
+### B5. Cache isolation omitted configuration identity and clone state
+
+**Finding:** Profile plus source name is insufficient. Current cache paths use
+source names, and clone-backed GitHub storage uses a repository slug without ref
+or profile identity.
+
+**Impact:** Renamed/reconfigured sources or the same repository at different
+refs could share stale or wrong content across profiles.
+
+**Resolution:** Accepted. The plan now hashes profile id plus the canonical
+source configuration—kind, root/endpoint/repository, ref, path selection, and
+adapter options—into every memory, disk, remote API, and clone namespace. Tests
+cover same-name/different-source and same-repo/different-ref cases.
+
+### B6. A one-time fixed backup could become stale or corrupt
+
+**Finding:** Creating one never-overwritten migration backup allows a failed
+first attempt to leave an old or partial file that later appears authoritative.
+
+**Impact:** Manual recovery could discard newer configuration.
+
+**Resolution:** Accepted. Backups are atomic, timestamped, and named/recorded
+with the source manifest SHA-256. Recovery verifies the content hash and warns
+that changes after the timestamp will be lost. No backup is restored
+automatically.
+
+### B7. Promotion remained path-based and outside profile isolation
+
+**Finding:** The draft required selected-profile promotion, but the current CLI
+accepts arbitrary source and target roots without reading a manifest.
+
+**Impact:** The requirement was unenforceable; a caller could promote between
+unrelated profile roots.
+
+**Resolution:** Accepted. The plan adds a profile-aware promotion entry point
+that resolves live and target layers by identity from one selected manifest and
+revalidates before writing. Raw-path promotion remains an explicitly separate
+legacy/advanced mode without a profile-isolation claim.
+
+## 2. Non-Blocking Findings and Resolutions
+
+| Finding | Disposition |
+|---|---|
+| Legacy `--profile default` reason contradicted the test matrix | Fixed: explicit override reports `explicit`; no override reports `legacy-default`. |
+| Dangling-reference validation classes were ambiguous | Fixed: fatal structure, inactive warning, and selected-fatal classes are explicit. |
+| Pack registry/layer invariants were incomplete | Fixed: bidirectional assignment/layer/version/origin/level validation and fixtures added. |
+| Automatic CWD routing lacked a five-client proof matrix | Fixed: every advertised client must be tested; unsupported clients are labeled Default/explicit rather than automatic. |
+| Profile labels lacked bounds and hostile-input handling | Fixed: NFC, trimming, 1–80 character bound, control/line-break and credential-pattern rejection. |
+
+## 3. Suggestions Applied
+
+- Added a sanitized real-world upgrade corpus from current Pack, team-sync,
+  signed-in sync, pending-source, and older desktop manifests.
+- Made dogfood reproducible: at least 30 starts, five per profile, ten per
+  harness, failed starts retained, timestamped local scoring.
+- Added deletion language explaining that running agents can retain snapshot
+  read access until restart; capture/promotion writes revalidate and fail after
+  profile deletion or live-layer change.
+
+## 4. Additional Primary-Agent Amendments
+
+The primary red-team pass also tightened two areas adjacent to the independent
+findings:
+
+- Equal-level sources remain explicit tie groups so visual reordering does not
+  silently erase the existing recency tie-break rule.
+- Pending synced sources and executable trust are separated: source metadata can
+  sync, but runnable commands and local activation cannot.
+
+## 5. Rejected Findings
+
+None. Every material finding was within the requested feature scope and improved
+the safety or testability of the plan.
+
+## 6. Review Exit Criteria
+
+The planning review is closed because:
+
+- every blocking finding has a concrete requirement, design response, test, or
+  rollout gate;
+- no unresolved marker or blocking product question remains;
+- the plan preserves the approved integration, auth, Packs, distribution, and
+  team-sync boundaries;
+- remaining risk is implementation risk, to be handled by per-PR review and the
+  seven-day dogfood gate rather than hidden in the planning document.
diff --git a/specs/contextcake-project-profiles/design.md b/specs/contextcake-project-profiles/design.md
new file mode 100644
index 0000000..1cb1562
--- /dev/null
+++ b/specs/contextcake-project-profiles/design.md
@@ -0,0 +1,915 @@
+# ContextCake Project Profiles — Delivery Plan
+
+How to deliver the approved profile model as one safe vertical slice across the
+dependency-free engine, MCP server, engine service, Mac app, Console, Packs,
+team sync, docs, and release validation.
+
+**Date:** 2026-07-28
+**Status:** Proposed — adversarial review complete; awaiting product approval
+**Spec:** `specs/contextcake-project-profiles/spec.md`
+**Estimated shape:** five implementation PRs plus a seven-day dogfood gate
+
+---
+
+## 1. Outcome
+
+At the end of this plan, a user installs ContextCake once, connects each AI
+harness once, and creates profiles such as `ContextCake`, `Mind Your Blanks`,
+and `Work`. Each profile contains only its relevant local folders, GitHub
+sources, Packs, and optional team live layer. Starting an agent inside a mapped
+folder automatically selects the matching profile.
+
+The release is complete only when the selection is visible, deterministic, and
+used consistently by every read and write path. A UI-only switcher over the
+existing flat manifest is not sufficient.
+
+## 2. Current State and Gaps
+
+### Already present
+
+- `files`, `okf-local`, MCP, cache, and git-sync source machinery.
+- A Mac app with a bearer-protected loopback engine service, native folder
+  picker, first-run source setup, CLI installation, and optional account sync.
+- One global `contextcake mcp` registration flow for Claude Code, Codex,
+  Cursor, Claude Desktop, and generic MCP clients.
+- Pack validation, immutable retained versions, rollback, registry assignments,
+  and CLI arguments that already accept `--profile`.
+- Team-sync live capture, promotion, and content-free telemetry.
+- An in-flight GitHub API adapter that follows the integration contract.
+
+### Missing or incomplete
+
+- `resolver.mjs`, `mcp-server.mjs`, and `service.mjs` still build only
+  top-level `manifest.layers`.
+- `resolveLiveLayer()` still searches only the flat layer array.
+- Pack management can write profile layers, but the runtime cannot resolve
+  them.
+- Manifest reads and mutations are duplicated; Pack writes are locked and
+  atomic, while service source CRUD currently writes directly.
+- The Console has source setup but no profile list, active-profile state,
+  project mappings, or scoped source management.
+- Desktop settings sync understands profile-shaped metadata but project-path
+  mappings need an explicit never-sync rule.
+- Current settings sync can persist a transitional document containing both
+  top-level `layers` and `profiles`, and can reconstruct scrubbed profile layers
+  without their runnable path/command. Upgrade logic must accept and normalize
+  that shipped shape rather than declaring it corrupt.
+- `activeProfile` is currently a sync field. It must become local-only before a
+  profile id can select locally trusted executable MCP sources.
+- Cache directories are keyed by source name and can collide when two profiles
+  reuse a layer name.
+- GitHub source setup currently has two meanings: the shipped service clones a
+  repo into a local cache, while the in-flight adapter reads GitHub's API. The
+  UI must not present those as one indistinguishable source.
+
+## 3. Non-Negotiable Invariants
+
+1. **Select once.** Manifest validation and profile selection happen before any
+   adapter, live layer, Pack assignment, or telemetry writer is initialized.
+2. **One stack per process/request context.** No operation receives the full
+   manifest after selection unless it is explicitly a configuration-management
+   operation.
+3. **Fail closed on an intended-but-invalid match.** An explicit or matched
+   invalid profile never falls through to unrelated default context.
+4. **Legacy is a first-class mode.** Reading a flat manifest causes no write and
+   no behavior change.
+5. **Local paths stay local.** Project mappings never enter account sync,
+   telemetry, MCP responses, or logs intended for sharing.
+6. **Deletion removes references, not knowledge.** Profile deletion cannot
+   delete user folders, git repositories, overlays, or retained Pack versions.
+7. **No new resolution rule.** Profiles choose a layer set; the existing level
+   and recency rules resolve that set unchanged.
+8. **The core stays dependency-free.** New core modules use Node.js built-ins.
+
+## 4. Manifest v2 Contract
+
+### 4.1 Canonical shape
+
+```json
+{
+  "profiles": {
+    "default": {
+      "label": "Default",
+      "layers": [
+        {
+          "name": "personal-notes",
+          "level": 3,
+          "source": "files",
+          "path": "/Users/dana/Notes"
+        }
+      ]
+    },
+    "context-cake": {
+      "label": "ContextCake",
+      "layers": [
+        {
+          "name": "repo-docs",
+          "level": 3,
+          "source": "files",
+          "path": "/Users/dana/repos/context-cake"
+        },
+        {
+          "name": "contextcake-pack",
+          "level": 0,
+          "source": "okf-local",
+          "path": "packs/contextcake/1.0.0",
+          "origin": "pack:contextcake@1.0.0"
+        }
+      ],
+      "pendingSources": []
+    }
+  },
+  "projects": {
+    "/Users/dana/repos/context-cake": "context-cake"
+  },
+  "packs": {}
+}
+```
+
+Rules:
+
+- A v2 manifest has `profiles` and no top-level `layers`.
+- `default` always exists and cannot be deleted.
+- Profile ids match `^[a-z0-9][a-z0-9-]{0,62}$`; labels are independent and may
+  change.
+- Labels are Unicode-NFC, trimmed, 1–80 display characters, and reject control
+  characters, line breaks, and recognized credential patterns before they can
+  enter MCP instructions, UI, logs, or sync.
+- `projects` keys are absolute local paths and values are profile ids.
+- Each profile contains its own complete `layers` array. v1 does not add a
+  second global source registry or cross-profile layer references.
+- Within a profile, the existing unique layer `name` is the v1 source identity;
+  sync and migration key it with profile id and source kind. Renaming is modeled
+  as remove/add and invalidates executable trust and cache identity.
+- `pendingSources[]` contains synced source descriptors that are not runnable on
+  this Mac. Pending sources are visible repair tasks and are never passed to an
+  adapter factory, resolver, MCP server, sync operation, or live-layer lookup.
+- `packs` remains a top-level retained-version registry; each assignment names
+  the profile that receives the Pack layer.
+- A profile may contain at most one `live: true` layer, preserving team sync's
+  existing rule on a per-profile basis.
+
+### 4.2 Legacy compatibility and migration
+
+Reading a flat `{ "layers": [...] }` manifest returns an in-memory selection:
+
+```js
+{
+  mode: "legacy",
+  profile: { id: "default", label: "Default", layers: manifest.layers },
+  reason: "legacy-default"
+}
+```
+
+It does not write the manifest. Migration occurs only when the app needs to
+persist more than one profile:
+
+1. Acquire the shared manifest mutation lock.
+2. Re-read and validate the latest manifest.
+3. Classify it as flat legacy or transitional hybrid. A transitional hybrid is
+   a currently shipped shape with top-level `layers` plus synced `profiles`,
+   `profilesOwnerUserId`, or `pendingSources`; it continues to run the flat
+   layers until this normalization.
+4. Write an atomic mode-`0600` backup named with a UTC timestamp and SHA-256 of
+   the source manifest. Verify the completed backup and return its path/hash in
+   the migration result; never present an older unmatched backup as current.
+5. Move the exact top-level `layers` array to `profiles.default.layers`. If a
+   synced `profiles.default` exists, merge descriptors by stable source identity:
+   locally runnable fields win and incomplete remote descriptors become pending
+   rather than overwriting local execution config.
+6. Preserve every existing named profile. Move any layer that lacks its required
+   machine-local configuration or local executable trust into that profile's
+   `pendingSources`; preserve owner-binding metadata used by settings sync.
+7. Move top-level `pendingSources` into `profiles.default.pendingSources`.
+8. Change every Pack assignment with `profile: null` to
+   `profile: "default"`.
+9. Add the new profile and any confirmed project mapping.
+10. Validate the complete v2 candidate and every Pack/profile reference, write a
+   mode-`0600` temporary file, and
+   atomically rename it over the manifest.
+11. Reload the service only after the rename succeeds.
+
+The migration is idempotent. A crash before manifest rename leaves the legacy or
+transitional manifest; a crash after rename leaves the complete v2 manifest.
+Backups are never read automatically. A recovery command verifies the backup's
+content hash and warns that restoring it discards changes made after its
+timestamp.
+
+### 4.3 Shared manifest module
+
+Create `packages/core/src/manifest.mjs` as the single boundary for:
+
+- parsing and structural validation;
+- detecting legacy versus v2 mode;
+- stable profile-id generation and validation;
+- selecting one profile;
+- listing profile summaries without opening sources;
+- validating and canonicalizing project mappings;
+- locked, atomic mutation and migration;
+- safe layer-array access for Pack and source mutations.
+
+Validation returns three classes instead of one undifferentiated error:
+
+- **fatal structure:** unsafe keys, malformed profiles/layers, invalid ids, or a
+  canonical v2 document with two active schema roots;
+- **inactive warning:** a stale mapping, pending source, or dangling reference in
+  an unselected profile;
+- **selected fatal:** an explicit/matched profile, Pack assignment, or live-layer
+  reference that cannot be made safe.
+
+Move the Pack manager's private lock/write helpers into this module. Source
+CRUD, profile CRUD, project mappings, and Pack operations must all use the same
+lock to prevent lost updates between the app and concurrent CLI processes.
+
+## 5. Selection Algorithm
+
+Expose one pure selection function plus a thin filesystem canonicalization
+step:
+
+```js
+selectManifestProfile(manifest, {
+  requestedProfile,
+  cwd,
+  realpath,
+}) -> {
+  mode,
+  profileId,
+  profileLabel,
+  layers,
+  reason,
+  matchedProjectRoot
+}
+```
+
+Order:
+
+1. Validate the manifest without opening a source, separating fatal structure
+   from inactive warnings.
+2. If flat legacy or transitional hybrid, return the top-level layers as the
+   virtual default stack. `--profile default` reports `reason: "explicit"`;
+   no override reports `legacy-default`; any other explicit id is an actionable
+   migration-required error.
+3. If `requestedProfile` exists, require that exact profile and return
+   `reason: "explicit"`.
+4. Canonicalize `cwd` and each existing mapping root with native `realpath`.
+5. A root matches when `path.relative(root, cwd)` is empty or stays inside the
+   root by path segments. Never use `cwd.startsWith(root)`.
+6. Sort matches by canonical root depth/length descending. The longest wins.
+7. If equal-specificity canonical roots point to different profiles, return a
+   configuration error.
+8. If the winning mapping names an unknown or invalid profile, fail closed.
+9. Otherwise require and return `profiles.default` with
+   `reason: "default"`.
+
+Stale roots and dangling references in inactive profiles are returned as
+warnings for the app and omitted from unrelated matching. A dangling reference
+that wins selection is fatal. Paths are never emitted to shared logs or
+telemetry.
+
+### Process binding
+
+- `contextcake mcp` selects once at startup from `--profile` and
+  `process.cwd()`. It never changes profile during the process lifetime.
+- `resolver`, future profile-aware commands, and `contextcake profile current`
+  use the same selector.
+- The desktop engine service selects from the app's persisted
+  `settings.activeProfile`; it does not use the app process working directory.
+- `settings.activeProfile` is local-only. Settings sync may deliver profile
+  metadata but never an activation command or operative activity hint.
+- A Console profile switch updates `settings.activeProfile`, tells the service
+  to replace its selected adapter set, and reloads all visible data.
+- Existing agent processes are unaffected by an app switch. The UI explains
+  that a new agent session is required after mappings change.
+
+## 6. Core and MCP Changes
+
+### 6.1 Source construction
+
+- Change `buildSources()` to receive a selected profile/layer array, or add a
+  narrowly named `buildSelectedSources(selection, manifestDir, options)`.
+- Prevent callers from passing a full v2 manifest without an explicit
+  selection.
+- Derive a non-secret source fingerprint from profile id, source kind,
+  endpoint/repository or canonical local root, ref, content-path selection, and
+  adapter options. Use its hash—not raw paths—in every memory/disk/API-cache
+  namespace before the existing encoded display name.
+- Move clone-backed GitHub checkouts from repository-slug-only paths to the same
+  profile/fingerprint namespace so the same repository at different refs cannot
+  share a mutable checkout. Explicit custom cache roots retain their location
+  contract but receive the fingerprint subdirectory.
+- Preserve adapter behavior, numeric levels, and current warn-and-continue
+  semantics.
+
+### 6.2 Resolver and compatibility wrappers
+
+- Parse `--profile` in `resolver.mjs`.
+- Select from the manifest before building sources.
+- Keep root compatibility wrappers forwarding arguments unchanged.
+- Update help and manifest documentation with selection order and examples.
+
+### 6.3 MCP server
+
+- Parse `--profile` without changing the existing boolean-flag behavior for
+  `--capture` and `--telemetry`.
+- Use one selection object for source construction, live-layer discovery,
+  capture context, link traversal, and telemetry initialization.
+- Make `resolveLiveLayer()` accept selected layers rather than search the full
+  manifest.
+- Add the profile label, id, and non-sensitive selection reason to MCP
+  initialization instructions. Do not include a project path.
+- Keep the four baseline read-tool schemas byte-for-byte stable and preserve the
+  two additional team-sync read tools.
+- Keep capture opt-in. The selector must complete before the server exposes
+  write tools.
+- Bind capture staging tokens to the selected profile id, manifest revision, and
+  live-layer identity. `confirm_capture` re-reads the manifest and rejects the
+  write if any binding changed or the profile was deleted.
+
+### 6.4 Promotion
+
+- Add a profile-aware promotion entry point that accepts `--manifest`, optional
+  `--profile`, the live capture id, and a target layer name from the selected
+  profile.
+- Resolve source and destination roots from that one selection; do not accept
+  arbitrary filesystem roots in profile-aware mode.
+- Retain the current raw-path promotion CLI only as a separately documented
+  legacy/advanced compatibility path. It carries no cross-profile isolation
+  claim.
+- Revalidate profile id, manifest revision, live-layer identity, and target
+  layer before the approval write.
+
+### 6.5 Profile CLI
+
+Add `contextcake profile` with:
+
+- `current [--profile <id>] [--json]` — show the selected profile and reason;
+- `list [--json]` — ids, labels, source count, mapping count, and validity;
+- `create <label> [--project <path>]` — headless counterpart to app creation;
+- `map <id> <path>` and `unmap <path>`;
+- `delete <id>` — refuse `default`, print affected references, require
+  `--confirm` in non-interactive use.
+
+Configuration commands use the shared mutation lock. `current` and `list` are
+read-only and never open source adapters.
+
+## 7. Engine Service API
+
+Extend the bearer-protected, same-origin service with profile-aware routes.
+Exact HTTP names can change during implementation if tests preserve the
+semantics.
+
+| Route | Method | Purpose |
+|---|---|---|
+| `/api/profiles` | GET | List profile summaries, active id, validation warnings |
+| `/api/profiles` | POST | Create profile; optionally copy layers and/or map a folder |
+| `/api/profiles/:id` | PATCH | Rename label or replace validated layer order |
+| `/api/profiles/:id` | DELETE | Remove non-default profile references after confirmation |
+| `/api/profiles/active` | POST | Change the app-selected profile and rebuild adapters |
+| `/api/projects` | POST | Add or replace a canonical project mapping |
+| `/api/projects` | DELETE | Remove one mapping without touching the folder |
+| `/api/sources` | POST/PATCH/DELETE | Existing source CRUD with explicit profile/revision target |
+| `/api/sources/sync` | POST | Sync one source with explicit profile/revision target |
+| `/api/graph` | GET | Existing graph plus selected profile id/label/reason |
+| `/api/resolve` | GET | Existing resolved concept in the profile/revision envelope |
+| `/api/resolve-all` | GET | Existing concept set in the profile/revision envelope |
+
+Service rules:
+
+- Configuration-list routes parse the full manifest but never open inactive
+  profile sources.
+- Read routes operate on a cached adapter set keyed by manifest stamp plus
+  active profile id.
+- A switch creates the new adapter set before publishing it. If initialization
+  fails, the prior active set remains available and the switch returns an
+  error.
+- Prior adapters close after the existing grace window so in-flight reads
+  complete.
+- Every profile-derived response—including graph, resolve, resolve-all,
+  fallback reads, source sync, and configuration mutations—carries immutable
+  `{profileId, manifestRevision}` metadata. The revision is a content-derived
+  digest or monotonic generation, not only mtime/size.
+- Every source, reorder, mapping, Pack-assignment, and delete mutation names its
+  target profile explicitly and supplies the revision it read. A stale
+  precondition returns `409 Conflict`; no mutation silently follows whichever
+  profile happens to be active at request time.
+- The renderer commits a load only after graph and resolved data share its
+  expected profile/revision pair; otherwise it discards the entire generation
+  and reloads.
+- Source names need be unique only within a profile.
+- GitHub clone source and GitHub API source receive distinct `kind` values and
+  labels until the clone path is intentionally retired; the API must never
+  silently reinterpret an existing source.
+
+## 8. Desktop and Console UX
+
+### 8.1 Persistent profile indicator
+
+Add a compact profile control near the ContextCake brand/sidebar top:
+
+- visible label and project/profile icon;
+- tooltip/accessible name: `Active profile: <label>`;
+- switcher showing label, source count, health, and mapped-folder count;
+- `Manage profiles…` and `New profile…` actions;
+- warning badge for stale mappings, missing sources, or a failed profile load.
+
+The control is present only in live/Desktop mode. Demo mode keeps its current
+fixed example and public behavior.
+
+### 8.2 Profile management surface
+
+Use Settings → Profiles as the primary management surface:
+
+- label and stable id;
+- local project-folder mappings with native picker;
+- ordered source stack, source kind, health, freshness, and precedence;
+- installed Pack assignments and version;
+- team-sync live-layer state where present;
+- rename, deliberate duplicate, and guarded delete actions.
+
+Layer order is shown from highest precedence to lowest. Equal-level layers stay
+in an explicit `same precedence; newest wins` group; drag/drop moves sources or
+whole tie groups without silently converting a recency tie into a strict rank.
+If levels need rebalancing, preserve tie groups and preview the exact old/new
+numeric values before saving. Show a compact preview of which source wins first.
+
+### 8.3 Creation flow
+
+1. Enter profile label; generate a stable id and reveal it as secondary text.
+2. Optionally select the local project folder.
+3. Choose `Start empty` (default) or `Copy sources from…`.
+4. Add the first source using the existing Markdown/ContextCake/GitHub/MCP
+   source flows.
+5. Optionally attach an already-installed Pack.
+6. Preview source precedence.
+7. Save, activate in the app, and offer `Test in my agent`.
+
+Creating the first additional profile from a legacy stack includes a plain
+migration explanation: the existing sources become `Default`; no content is
+moved or deleted.
+
+Copying a profile duplicates local layer configuration but does not copy an
+executable-source trust grant: MCP commands are disabled in the copy until the
+user confirms the exact command/arguments again. Synced incomplete descriptors
+appear under `Needs setup`, never in the active layer order.
+
+### 8.4 Switching behavior
+
+- Switch optimistically only after the service accepts the new profile.
+- Key graph/query state by profile id.
+- Abort fetches where possible and discard any response whose profile id no
+  longer matches the current selection.
+- Clear selected concept, detail drawer, search query, canvas positions, and
+  profile-derived counts on successful switch. Preserve theme and sidebar
+  preferences.
+- Announce the change through an ARIA live region and move focus predictably.
+- State explicitly: `This changes the ContextCake app. Running agents keep the
+  profile they started with.`
+- Profile deletion adds: `Running agents may retain read access until they are
+  restarted. Pending capture and promotion writes will be rejected after this
+  profile is removed.` Deletion is not presented as immediate credential
+  revocation.
+
+### 8.5 Connect an Agent update
+
+Keep the global registration commands unchanged. Add:
+
+1. Map a project folder to the intended profile.
+2. In Terminal, `cd` to that project.
+3. Run `contextcake profile current` and confirm the label.
+4. Start or restart the chosen harness.
+5. Ask it to call `list_concepts`, identify its selected ContextCake profile,
+   summarize contributing layers, and surface conflicts.
+
+Offer explicit-profile registration only in an advanced disclosure for clients
+that do not preserve a useful working directory.
+
+Do not infer client behavior from registration scope. Before release, launch the
+packaged CLI from Claude Code, Codex, Cursor, Claude Desktop, and the documented
+generic-client fixture and record the actual server working directory. A client
+earns the `automatic project mapping` label only if the project cwd reaches the
+server reliably. Otherwise its primary copy says `uses Default`; its documented
+alternative registers `contextcake mcp --profile <id>` under a separately named
+server. The seven-day gate uses two clients that passed automatic-cwd proof, but
+the documentation matrix covers all five advertised clients.
+
+## 9. Packs Integration
+
+The Pack registry already models profile assignments, but its runtime and
+mutation behavior must be aligned with Manifest v2.
+
+- Replace `selectProfileLayers()` in `pack-manager.mjs` with the shared manifest
+  module.
+- Add `attachInstalledPack({packId, version, profile, level})` so one retained
+  immutable version can be referenced by another profile without copying or
+  re-ingesting customer content.
+- Keep assignments independent: two profiles may use different retained
+  versions or precedence levels.
+- On profile deletion, remove its Pack assignments and layer references in the
+  same locked manifest transaction.
+- Validate Pack state bidirectionally before mutation: each assignment's
+  profile, `layerName`, `activeVersion`, and level must match exactly one profile
+  layer whose `origin` names the same Pack/version, and that immutable version
+  must exist in the retained-version registry. Duplicate assignments, orphan
+  origins, missing layers/versions, or mismatched levels make the selected
+  profile invalid until repaired.
+- Garbage collection of unreferenced retained versions is out of scope and must
+  never happen implicitly.
+- The Console may attach/detach already-installed Packs. Download, checkout,
+  entitlements, and marketplace browsing remain outside this release.
+
+## 10. Team Sync Integration
+
+- Change `resolveLiveLayer()` to accept the selected profile id/layers and
+  return that profile id with the live-layer facade.
+- Bind staged capture tokens to profile id as defense in depth, even though an
+  MCP process is already profile-fixed; confirmation revalidates the current
+  manifest revision and live-layer identity so a deleted profile cannot keep
+  accepting writes from an old process.
+- Include profile id in local capture-operation context but do not widen the
+  locked shared telemetry event schema.
+- Promotion uses the profile-aware entry point in §6.4. Destinations resolve by
+  selected-profile layer identity; reject a target that exists only in another
+  profile or changed after staging.
+- The app displays live-layer sync health only for the active profile.
+- Tests must prove that equal live-layer names in different profiles cannot
+  cross-read, cross-write, share a cache entry, or affect each other's queued
+  git state.
+
+## 11. GitHub Source Integration Boundary
+
+Project Profiles should consume the GitHub adapter rather than redesign it.
+Before presenting `GitHub repository` as a remote profile source:
+
+- merge and rebase the adapter against current `main`;
+- preserve its read-only API, path allowlist, cache, stale-read, and
+  warn-and-continue contracts;
+- inject tokens by value from the desktop credential broker; the engine never
+  opens the Keychain;
+- use a distinct integration credential from optional ContextCake account
+  sign-in;
+- store only `auth: "keychain:<alias>"` in the manifest;
+- support public repositories without a token and private repositories only
+  after the approved GitHub device-flow/keychain path is complete;
+- label the older clone-backed setup accurately if it remains available during
+  transition.
+
+The profile release is still useful with local repository folders, Obsidian,
+and Markdown wiki exports. Private-GitHub auth may land as a prerequisite PR or
+a clearly labeled fast-follow, but must not be simulated with a raw token field.
+
+## 12. Account Sync and Privacy
+
+Update the sync allowlist deliberately:
+
+| Field | Sync behavior |
+|---|---|
+| Profile id and label | Allowed |
+| Presentation preference | Allowed |
+| Scrubbed source descriptor | Allowed under existing rules |
+| Active app profile id | Local-only; remote values are ignored and no activity hint is applied |
+| Project mapping/path | Never uploaded |
+| Local source/cache/Pack path | Scrubbed or omitted |
+| MCP command and args | Scrubbed; local reconfirmation required |
+| Keychain alias/token/env value | Omitted |
+| Context, prompts, captures, telemetry bodies | Never uploaded |
+
+On a second Mac, synced profiles appear as incomplete shells whose source
+descriptors live in `pendingSources` until the user maps local folders and
+confirms executable sources. Pending sources are structurally valid metadata,
+not runnable layers. They cannot poison another healthy profile. A remote
+profile deletion removes metadata references only; local content remains
+untouched.
+
+Settings sync cannot delete or replace the local `default` runnable stack merely
+because a remote snapshot omits it. A remote default deletion/invalid shape is a
+sync error; complete local runnable fields survive scrub markers and profile
+shell merge until the user edits them locally.
+
+Executable MCP trust is a machine-local digest over profile id, source identity,
+command, and arguments, optionally owner-bound when signed in. The digest is
+never synced. Copying a profile, changing execution config, pulling a scrubbed
+remote descriptor, or switching accounts invalidates trust until the source is
+confirmed locally. This prevents synced ids/names from activating a preserved
+local command through merge-by-identity behavior.
+
+Project ids and selection reasons are not added to team telemetry in this
+release. Dogfood measurement uses a local, manual scorecard so the privacy
+contract does not expand merely to measure the feature.
+
+## 13. Error and Recovery Model
+
+| Failure | Required behavior |
+|---|---|
+| Missing/invalid manifest | Fail before opening sources; show repair guidance |
+| Shipped hybrid manifest | Preserve flat runtime; offer atomic normalization |
+| Unknown explicit profile | Exit non-zero; list valid profile ids |
+| Mapping to unknown profile | Fail closed when that mapping matches |
+| Stale/missing mapped folder | Mark warning; ignore for unrelated cwd |
+| Synced source missing local config/trust | Keep pending and disabled; healthy profiles still work |
+| Source fails inside selected profile | Warn and continue with healthy selected layers |
+| New app profile fails to initialize | Keep prior app profile active |
+| Manifest mutation lock timeout | Make no write; ask user to retry |
+| Crash during migration/write | Old or complete new manifest survives; never partial JSON |
+| Profile switch response arrives late | Renderer discards it by profile id/generation |
+| Mutation revision is stale | Return 409; reload before the user retries |
+| Pack assignment references missing version | Mark profile invalid; do not drop layer silently |
+| Selected profile has multiple live layers | Disable capture for that process and show repair error |
+| GitHub credential unavailable | Public read if allowed; otherwise warn and continue from safe cache |
+| Synced active-profile value | Ignore; active profile is a local-only preference |
+
+## 14. Implementation Sequence
+
+### PR 1 — Manifest v2 selector and mutation safety
+
+**Purpose:** establish the trust boundary before any UI writes profile data.
+
+Primary changes:
+
+- add `packages/core/src/manifest.mjs`;
+- add schema validation, legacy view, v2 selection, realpath-safe matching,
+  migration, backup, shared lock, and atomic writes;
+- refactor Pack manager to use the shared manifest boundary;
+- add source-fingerprint cache namespaces and Pack registry invariants;
+- define transitional hybrid and per-profile pending-source normalization;
+- document the Manifest v2 contract.
+
+Validation:
+
+- legacy manifests resolve byte-equivalently and remain unmodified;
+- flat and shipped-hybrid migration fixtures preserve every layer field, named
+  profile, pending/owner metadata, and Pack assignment;
+- explicit/project/default selection table tests;
+- nested roots, sibling-prefix traps (`/app` versus `/app-old`), symlinks,
+  unknown mappings, duplicate canonical paths, forbidden keys, and lock races;
+- concurrent Pack and profile mutation test proves neither update is lost;
+- atomic backup/hash/retry tests prove a failed first attempt cannot make a
+  stale backup look current.
+
+### PR 2 — Runtime selection across resolver, MCP, and team sync
+
+**Purpose:** prove every engine path uses the same selected stack.
+
+Primary changes:
+
+- `--profile` and automatic cwd selection in resolver/MCP;
+- profile-bound live-layer discovery, capture, promotion, and telemetry context;
+- profile-aware promotion command/API plus explicit legacy raw-path mode;
+- dynamic profile information in MCP initialization instructions;
+- complete `contextcake profile current/list/create/map/unmap/delete` CLI;
+- compatibility-wrapper and CLI help updates.
+
+Validation:
+
+- cross-profile sentinel fixtures for search/read/list/links;
+- MCP process cwd and explicit-override integration tests;
+- original four tool schemas remain byte-identical;
+- capture and promotion write only into selected-profile fixtures;
+- profile deletion/config change between capture staging and confirmation blocks
+  the write;
+- same source/live-layer names in two profiles never collide;
+- flat-manifest root suite remains green.
+
+### PR 3 — Engine service and profile-scoped configuration API
+
+**Purpose:** make safe profile management possible from the app.
+
+Primary changes:
+
+- add profile/project routes and profile-aware source CRUD;
+- key adapter cache by manifest stamp plus active profile;
+- envelope every profile-derived response and precondition every mutation with
+  profile id plus manifest revision;
+- preserve the prior active adapter set on failed switch;
+- persist app-active profile through the desktop settings seam;
+- extend loopback service tests for auth, CSRF, path validation, deletion, and
+  concurrent mutation.
+
+Validation:
+
+- service tests exercise create/map/switch/reorder/delete end to end;
+- inactive MCP sources are never spawned during active-profile reads;
+- graph/resolve-all/fallback response generations cannot be mixed and stale
+  mutation preconditions return 409;
+- settings pulls cannot activate a local profile or executable MCP source;
+- same repository/different ref clone-backed sources use distinct checkouts;
+- profile deletion leaves fixture directories and retained Packs intact.
+
+### PR 4 — Mac/Console Project Profiles UX
+
+**Purpose:** deliver the user-visible workflow.
+
+Primary changes:
+
+- persistent profile indicator and accessible switcher;
+- Settings → Profiles management surface;
+- native project-folder mapping;
+- profile-scoped source setup, health, sync, and reordering;
+- installed-Pack attach/detach;
+- migration explanation and guarded deletion;
+- pending-source repair and local executable-trust confirmation;
+- revised Connect an Agent verification flow.
+
+Validation:
+
+- component tests for creation, mapping, switching, stale responses, empty
+  profiles, ordering, Pack assignment, and deletion confirmation;
+- typecheck and both demo/live builds;
+- keyboard-only, focus, 200% text, narrow-window, light, and dark checks;
+- visual behavior check in the packaged Mac app, not only browser demo mode;
+- launch-CWD proof for every advertised harness; clients without reliable CWD
+  are accurately labeled and tested with default/explicit profile setup;
+- label normalization/length/control-character/credential-pattern tests;
+- public demo remains unchanged.
+
+### PR 5 — GitHub vertical slice, docs, and release hardening
+
+**Purpose:** prove a useful mixed-source profile and prepare the dogfood build.
+
+Primary changes:
+
+- land/reconcile the GitHub adapter and profile-aware cache namespace;
+- finish public-repo setup and, if credential work is ready, private-repo
+  device flow/keychain injection;
+- distinguish remote API and clone-backed sources in UI/docs;
+- update manifest, CLI, privacy, Packs, team-sync, and getting-started docs;
+- create a three-profile demo fixture and dogfood runbook;
+- package a signed/notarized candidate when release credentials are available.
+
+Validation:
+
+- root `npm test` and `npm run demo:verify`;
+- Console typecheck, tests, demo build, and live build;
+- desktop tests, navigation tests, CLI-status tests, smoke tests, and packaged
+  app behavior;
+- site build and link validation;
+- fresh install plus legacy-manifest upgrade rehearsal;
+- signed artifact Gatekeeper/notarization checks before distribution.
+
+If private GitHub auth is not ready, PR 5 ships local folders plus clearly
+labeled public GitHub support and records private GitHub as an unmet acceptance
+gate. It must not accept pasted raw tokens as a shortcut.
+
+## 15. Test Matrix
+
+### Core selection matrix
+
+| Manifest | Explicit id | CWD | Expected |
+|---|---|---|---|
+| Legacy flat | none | anywhere | virtual `default`, `legacy-default` |
+| Legacy flat | `default` | anywhere | virtual `default`, `explicit` |
+| Legacy flat | other | anywhere | error |
+| V2 | valid id | mapped elsewhere | explicit id |
+| V2 | none | nested mapped root | deepest mapped profile |
+| V2 | none | sibling prefix only | `default` |
+| V2 | none | no match | `default` |
+| V2 | unknown explicit | any | fail closed |
+| V2 | matched mapping to unknown id | inside root | fail closed |
+| V2 | equal canonical aliases to different ids | inside root | config error |
+
+### Isolation matrix
+
+For two profiles containing same-named layers and unique sentinel concepts,
+assert isolation across:
+
+- source construction and MCP child spawning;
+- search, read, list, and links;
+- disk and memory cache;
+- explicit sync;
+- Pack version assignment;
+- live capture staging/confirmation;
+- queued git writes and promotion;
+- service graph and Console state;
+- response revision mixing and stale mutation preconditions;
+- clone-backed GitHub checkouts for same repo/different refs.
+
+### Migration matrix
+
+- no Packs, one local layer;
+- installed Pack with `profile: null`;
+- live layer with git config;
+- MCP source with command/args;
+- pending/scrubbed synced source metadata;
+- shipped hybrid shape with top-level layers, named profiles,
+  `profilesOwnerUserId`, and top-level pending sources;
+- concurrent CLI Pack update during app profile creation;
+- interrupted write before and after atomic rename;
+- rerun after completed migration.
+
+Fixtures include sanitized manifests captured from the current Pack CLI,
+team-sync setup, signed-in settings sync, pending-source flow, and at least one
+older packaged desktop release. Synthetic shapes alone are not an adequate
+upgrade corpus.
+
+### UX matrix
+
+- new install;
+- existing flat-manifest upgrade;
+- empty profile;
+- nested project mapping;
+- missing mapped directory;
+- broken source and healthy sibling source;
+- profile switch during slow graph load;
+- default and non-default deletion paths;
+- signed-out and signed-in settings sync;
+- synced active-profile injection and profile/source id collisions;
+- pending-source repair and executable trust invalidation after copy/account change;
+- keyboard-only and screen-reader announcements;
+- 1280px, narrow desktop, and 200% text layouts;
+- light and dark themes.
+
+## 16. Seven-Day Dogfood Plan
+
+### Setup
+
+Create at least three profiles with materially different context:
+
+1. **ContextCake** — this repository, relevant local notes, ContextCake Pack.
+2. **A second software/product project** — its repository and project docs.
+3. **Work or personal knowledge** — a Markdown wiki export or Obsidian folder,
+   with no ContextCake repository content.
+
+Use at least Codex and Claude Code. Keep the global MCP registration identical
+in both.
+
+### Daily scorecard
+
+Record locally, without uploading paths or content:
+
+- harness and session number;
+- expected profile and reported selection reason;
+- correct/incorrect automatic selection;
+- whether a manual override was needed;
+- whether any unrelated concept appeared;
+- whether a missing source blocked the task;
+- whether provenance/conflicts changed the answer;
+- setup or recovery friction in minutes.
+
+### Pass gate
+
+- 100% correct profile selection for mapped-project starts;
+- zero cross-profile reads, cache hits, captures, or Pack assignments;
+- at least 90% of mapped starts need no override;
+- selected profile identifiable in under ten seconds;
+- successful use from both harnesses;
+- no high-severity data-loss, path-disclosure, or stuck-migration issue;
+- at least one useful workflow combines two or more source layers in a profile.
+
+The scorecard must contain at least 30 starts, at least five per profile, and at
+least ten per harness. Failed starts and wrong defaults remain in the denominator;
+the operator records timestamps at session start and when profile identity is
+confirmed rather than estimating later.
+
+### Decision after the trial
+
+- If selection or trust fails, fix profiles before expanding sources.
+- If selection passes but a source is repeatedly missing, build the connector
+  evidenced by the scorecard.
+- If daily value is weak despite correct routing, revisit the product workflow
+  before investing in billing or marketplace breadth.
+- If the trial passes and Packs are repeatedly useful, prioritize the first
+  customer-facing Pack/install pilot next.
+
+## 17. Rollout and Reversal
+
+1. Merge each PR only after its slice passes the root required gate and its
+   surface-specific tests.
+2. Keep v2 writes behind profile-creation actions until the full app UI lands;
+   flat users remain on the legacy path.
+3. Dogfood with a prerelease Mac build and explicit backup verification.
+4. Do not call the feature shipped until a signed/notarized artifact is tested
+   on a clean install and an upgrade from a real flat manifest.
+5. On a severe runtime issue, users can remove project mappings or explicitly
+   invoke `--profile default`; no automatic downgrade rewrites a v2 manifest.
+6. Manual recovery may restore a verified timestamped/hash-named
+   `manifest.json.pre-profiles.*.json` backup only after the app is stopped and
+   the current manifest is preserved for diagnosis.
+
+## 18. Documentation Deliverables
+
+- Manifest reference: v2 schema, legacy behavior, selection precedence, path
+  privacy, examples.
+- CLI reference: `profile` commands and `--profile` override.
+- Getting started: create one profile, map a folder, add a source, connect once,
+  verify from an agent.
+- Packs: attaching one retained Pack to multiple profiles.
+- Team sync: one live layer per selected profile and process binding.
+- Updates and privacy: project paths never sync; second-Mac repair behavior.
+- Troubleshooting: wrong profile, stale mapping, unknown profile, failed
+  migration, missing source, app versus running-agent selection.
+- Dogfood runbook and local scorecard template.
+
+## 19. Definition of Done
+
+Project Profiles are done when:
+
+- every acceptance criterion in `spec.md` is either met or explicitly reported
+  as an open release gate;
+- the legacy flat-manifest suite remains green without migration-on-read;
+- cross-profile isolation tests cover reads, caches, Packs, and capture writes;
+- one global MCP registration routes correctly from mapped working directories;
+- the Mac app supports the complete create/map/source/order/switch/delete flow;
+- the packaged-app upgrade rehearsal preserves the user's existing stack;
+- the seven-day dogfood gate passes;
+- the canonical documentation matches the shipped artifact;
+- no Slack, Confluence, Google Drive, hosted context, billing, or marketplace
+  scope has slipped into the release.
diff --git a/specs/contextcake-project-profiles/spec.md b/specs/contextcake-project-profiles/spec.md
new file mode 100644
index 0000000..decfcad
--- /dev/null
+++ b/specs/contextcake-project-profiles/spec.md
@@ -0,0 +1,390 @@
+# ContextCake Project Profiles
+
+Project Profiles let one ContextCake installation serve the correct, isolated
+source stack for each local project. A user connects an AI harness once; when
+the harness starts inside a mapped project folder, ContextCake selects that
+project's profile automatically and exposes only its sources, Packs, live
+captures, provenance, and conflicts.
+
+**Date:** 2026-07-28
+**Status:** Proposed — adversarial review complete; awaiting product approval
+**Workflow:** Requirements-First delivery slice of the approved profiles work in
+`specs/contextcake-integrations/spec.md`
+**Depends on:** `specs/contextcake-core/design.md`,
+`specs/contextcake-integrations/spec.md`,
+`specs/contextcake-distribution/design.md`,
+`specs/contextcake-harness-connect/spec.md`,
+`specs/contextcake-packs/spec.md`, and
+`specs/contextcake-team-sync/spec.md`
+
+---
+
+## 1. Problem Statement
+
+ContextCake can already resolve layered local knowledge, connect to AI
+harnesses, install Packs, and maintain a git-backed live layer. Today those
+capabilities still assume one flat `layers[]` stack. A user working across
+multiple projects must either combine unrelated context into that one stack or
+manually maintain separate manifests and MCP registrations.
+
+That breaks the core product promise in two ways:
+
+1. **Relevance:** an agent working on Project A can receive noise from Project
+   B, increasing token use and making the resolved answer less useful.
+2. **Trust:** unrelated or sensitive context can cross a project boundary. A
+   profile mistake is therefore not just inconvenient; it is a data-isolation
+   failure.
+
+Project Profiles make the local project folder the automatic routing signal.
+Each profile owns an explicitly ordered layer stack. The Mac app makes the
+active profile visible and manageable, while `contextcake mcp` selects a
+profile from the harness working directory without requiring another MCP
+registration.
+
+## 2. Product Terms
+
+- **Project profile:** a stable profile id, human-readable label, and ordered
+  list of ContextCake layers.
+- **Project mapping:** a machine-local association from an absolute folder path
+  to a project profile.
+- **Selected profile:** the single profile chosen for one engine or MCP process.
+- **Active profile:** the profile currently displayed by the Mac app. This is a
+  UI preference; it does not override working-directory selection in an agent.
+- **Default profile:** the required fallback profile when no explicit profile or
+  project mapping applies.
+- **Legacy stack:** an existing manifest containing top-level `layers[]` and no
+  `profiles` object. It behaves as a virtual default profile until the user
+  creates another profile.
+
+## 3. Goals
+
+- Let a user create and manage separate source stacks for separate projects.
+- Let a globally registered MCP server choose the correct stack from the
+  harness working directory.
+- Make the selected profile and selection reason inspectable before the user
+  trusts an answer.
+- Guarantee that reads, searches, links, sync, Packs, live capture, promotion,
+  and telemetry all operate on the same selected stack.
+- Preserve existing flat manifests without forcing migration on upgrade.
+- Keep project paths, local source paths, commands, credentials, and context
+  content local to the machine.
+- Validate the daily-use value through a bounded dogfood trial before expanding
+  into more connectors or commerce work.
+
+## 4. User Stories
+
+- As a person working across several repositories, I can map each repository to
+  its own profile so agents receive only relevant context.
+- As a first-time user, I can keep using the default profile without learning
+  profile terminology.
+- As an existing user, I can upgrade without losing or rewriting my flat
+  manifest until I deliberately create another profile.
+- As a desktop user, I can create, rename, inspect, switch, and delete profiles
+  without editing JSON.
+- As a user, I can add Markdown folders, ContextCake folders, GitHub sources,
+  trusted MCP sources, and installed Packs to one profile and control their
+  precedence.
+- As a cautious user, I can see why a profile was selected and verify it before
+  asking project-sensitive questions.
+- As a team-sync user, a capture is written only to the live layer belonging to
+  the selected profile.
+- As a CLI user, I can explicitly select a profile when automatic selection is
+  inappropriate.
+- As a user with two nested projects, the most specific mapped folder wins.
+- As a signed-in user, I can sync safe profile metadata without uploading local
+  folder mappings or executable source configuration.
+
+## 5. Acceptance Criteria
+
+### 5.1 Manifest and backward compatibility
+
+- [ ] WHEN a manifest contains top-level `layers[]` and no `profiles` object THE
+  SYSTEM SHALL treat those layers as one virtual profile with id `default` and
+  SHALL preserve existing resolver, MCP, service, Pack, and team-sync behavior.
+- [ ] WHEN a user creates the first additional profile from a legacy manifest
+  THE SYSTEM SHALL atomically migrate the existing layers into
+  `profiles.default.layers`, preserve their order and every layer field, migrate
+  default-stack Pack assignments to profile `default`, and create an atomic,
+  timestamped, content-hashed pre-migration backup.
+- [ ] WHEN a currently supported transitional manifest contains both top-level
+  `layers[]` and synced `profiles` metadata THE SYSTEM SHALL preserve the
+  top-level layers as the active legacy stack until an atomic normalization
+  moves them into `profiles.default`; inactive synced metadata SHALL NOT be
+  opened as runnable sources before normalization.
+- [ ] WHEN a canonical v2 manifest is written THE SYSTEM SHALL require a
+  `profiles.default` entry and SHALL omit top-level `layers[]`; newly created
+  split-brain documents SHALL be rejected while shipped transitional documents
+  remain eligible for the defined migration.
+- [ ] WHEN a manifest mutation occurs THE SYSTEM SHALL validate the complete
+  candidate document before an atomic replacement and SHALL serialize
+  concurrent mutations so source, profile, project-mapping, and Pack operations
+  cannot overwrite one another.
+- [ ] WHEN a profile id is created THE SYSTEM SHALL make it stable and
+  URL/CLI-safe; renaming the visible label SHALL NOT change the id or break
+  mappings and Pack assignments.
+- [ ] WHEN profile metadata arrives from settings sync without its required
+  machine-local path, command, credential, or trust confirmation THE SYSTEM
+  SHALL store it as an explicitly pending, non-runnable source and SHALL NOT let
+  it invalidate or enter any healthy profile's selected layer stack.
+
+### 5.2 Deterministic selection
+
+- [ ] WHEN `contextcake mcp` or another profile-aware CLI command receives
+  `--profile <id>` THE SYSTEM SHALL select that profile before inspecting the
+  working directory.
+- [ ] WHEN there is no explicit profile THE SYSTEM SHALL canonicalize the
+  process working directory and select the profile belonging to the longest
+  containing project-path mapping, using path-segment containment rather than a
+  raw string prefix.
+- [ ] WHEN no project mapping matches THE SYSTEM SHALL select the required
+  `default` profile.
+- [ ] WHEN two mappings could match through aliases or symlinks THE SYSTEM SHALL
+  use canonical real paths and reject an equal-specificity conflict rather than
+  choosing nondeterministically.
+- [ ] WHEN an explicit profile or a matched project mapping names an unknown or
+  invalid profile THE SYSTEM SHALL fail closed with an actionable error and
+  SHALL NOT fall back to another profile.
+- [ ] WHEN a stale mapping points to a folder that no longer exists THE SYSTEM
+  SHALL mark it invalid in the app and ignore it for unrelated working
+  directories; it SHALL NOT block use of the default profile.
+- [ ] WHEN validation finds an invalid structure THE SYSTEM SHALL treat it as a
+  fatal manifest error; WHEN it finds an inactive dangling mapping or pending
+  source THE SYSTEM SHALL surface a warning; WHEN that dangling reference is
+  selected or matched THE SYSTEM SHALL fail closed.
+- [ ] WHEN a legacy manifest is used without an override THE SYSTEM SHALL report
+  `legacy-default`; WHEN `--profile default` is explicit THE SYSTEM SHALL report
+  `explicit`; v2 automatic reasons SHALL be `project` or `default`.
+
+### 5.3 Isolation across every behavior
+
+- [ ] WHEN a profile is selected THE SYSTEM SHALL construct adapters only for
+  that profile's layers; sources belonging only to another profile SHALL NOT be
+  opened, queried, synced, spawned, or included in output.
+- [ ] WHEN MCP read tools run THE SYSTEM SHALL search, list, resolve, and follow
+  links only inside the selected profile.
+- [ ] WHEN capture or telemetry is enabled THE SYSTEM SHALL discover the live
+  layer only inside the selected profile and SHALL reject zero or multiple live
+  layers in that profile without inspecting other profiles.
+- [ ] WHEN a capture is staged, confirmed, synced, or promoted THE SYSTEM SHALL
+  remain bound to the profile selected when the MCP process started; changing
+  the Mac app's active profile SHALL NOT redirect a running agent process.
+- [ ] WHEN cache or clone storage is shared by multiple profiles THE SYSTEM
+  SHALL namespace memory, disk, remote-adapter, and clone state by profile plus
+  a canonical source-configuration fingerprint so equal names, renamed sources,
+  and the same repository at different refs cannot collide or disclose content.
+- [ ] WHEN a profile changes or is deleted THE SYSTEM SHALL leave source files,
+  retained Pack versions, local overlays, and live-layer repositories intact
+  unless the user separately requests their deletion.
+- [ ] WHEN a running agent attempts a capture confirmation or promotion after
+  its selected profile or live-layer identity changed or was deleted THE SYSTEM
+  SHALL revalidate the binding and reject the write; existing reads MAY continue
+  from the process snapshot until that agent is restarted.
+- [ ] WHEN promotion is requested in profile-aware mode THE SYSTEM SHALL select
+  a manifest profile and target a layer identity within that profile rather than
+  accept unrelated source and destination filesystem roots.
+
+### 5.4 Mac app management
+
+- [ ] WHEN the app opens with a configured cascade THE SYSTEM SHALL show the
+  active profile label in persistent app chrome without displacing the primary
+  navigation.
+- [ ] WHEN the user opens the profile switcher THE SYSTEM SHALL list profiles,
+  show the current selection, allow keyboard selection, and explain that the
+  switch changes the app view but not already-running agent sessions.
+- [ ] WHEN the user creates a profile THE SYSTEM SHALL request a label, offer a
+  project-folder mapping, and start with either an empty source stack or a
+  deliberate copy of an existing profile; the default SHALL be empty.
+- [ ] WHEN a copied or synced profile contains an executable MCP source THE
+  SYSTEM SHALL keep that source disabled until its exact local configuration is
+  confirmed; executable trust SHALL be bound to a local configuration digest
+  that changes with profile id, command, or arguments.
+- [ ] WHEN the user maps a folder THE SYSTEM SHALL use the native folder picker,
+  show nested-mapping precedence, reject duplicate/conflicting canonical paths,
+  and keep the absolute path on the local machine.
+- [ ] WHEN the user manages a profile THE SYSTEM SHALL let them add, remove,
+  inspect, sync, and reorder its layers with the existing trust confirmation for
+  executable MCP sources.
+- [ ] WHEN layer precedence changes THE SYSTEM SHALL display the resulting
+  highest-to-lowest order before saving and SHALL preserve numeric levels in the
+  manifest.
+- [ ] WHEN a profile has no usable sources THE SYSTEM SHALL show an empty-state
+  route to source setup and SHALL NOT present agent connection as ready.
+- [ ] WHEN the user attempts to delete `default` THE SYSTEM SHALL refuse; WHEN
+  the user deletes another profile THE SYSTEM SHALL show affected project
+  mappings and Pack assignments, warn that running agents may retain read access
+  until restart, and require confirmation before removing only those references.
+
+### 5.5 Packs and team sync
+
+- [ ] WHEN an installed Pack is attached to a profile THE SYSTEM SHALL add its
+  immutable base layer only to that profile and SHALL preserve its local overlay
+  and retained versions.
+- [ ] WHEN the same Pack is attached to multiple profiles THE SYSTEM SHALL reuse
+  the retained immutable files while keeping version assignment and precedence
+  explicit per profile.
+- [ ] WHEN a Pack is detached or a profile is deleted THE SYSTEM SHALL remove
+  only the relevant assignment and layer reference; it SHALL NOT delete Pack
+  files still referenced by another profile.
+- [ ] WHEN Pack configuration is validated THE SYSTEM SHALL verify the
+  bidirectional relationship among registry assignment, profile id, layer name,
+  active version, level, layer origin, retained version, and actual profile
+  layer before mutation.
+- [ ] WHEN a profile contains a team-sync live layer THE SYSTEM SHALL display
+  its capture state and sync health within that profile and SHALL enforce the
+  existing one-live-layer-per-profile rule.
+
+### 5.6 Agent connection and verification
+
+- [ ] WHEN an MCP process initializes THE SYSTEM SHALL include the selected
+  profile label, id, and selection reason in its non-secret usage instructions
+  without changing the existing read-tool schemas.
+- [ ] WHEN a user runs `contextcake profile current` THE SYSTEM SHALL report the
+  selected profile, selection reason, and matched project root if applicable;
+  machine-readable JSON SHALL be available.
+- [ ] WHEN Connect an Agent renders instructions THE SYSTEM SHALL keep one
+  global MCP registration and add a verification step that runs from a mapped
+  project and confirms the expected profile before calling `list_concepts`.
+- [ ] WHEN an advertised harness does not launch a global MCP server with the
+  project as its working directory THE SYSTEM SHALL label automatic mapping as
+  unavailable for that client and provide a tested default-profile or explicit
+  profile setup instead of implying automatic routing.
+- [ ] WHEN an explicit override is needed THE generated guidance SHALL document
+  `contextcake mcp --profile <id>` as a separate opt-in registration, not as the
+  default setup.
+
+### 5.7 Privacy, security, and account sync
+
+- [ ] WHEN settings sync prepares a payload THE SYSTEM SHALL omit the active app
+  profile, project-path
+  mappings, matched roots, local source paths, cache paths, executable MCP
+  commands/arguments, credentials, and context content.
+- [ ] WHEN safe profile metadata syncs THE SYSTEM MAY include stable profile ids,
+  labels, presentation preferences, and scrubbed source descriptors, but a new
+  Mac SHALL require local folder mapping and executable-source confirmation.
+- [ ] WHEN a remote settings snapshot omits, deletes, or incompletely describes
+  `default` THE SYSTEM SHALL NOT delete or replace the local runnable default
+  stack; it SHALL surface a sync error or pending repair state while preserving
+  local use.
+- [ ] WHEN profile, source, Pack, or project-mapping input contains prototype
+  keys, traversal, malformed encoded values, raw credentials, or unsupported
+  fields THE SYSTEM SHALL reject it before persistence.
+- [ ] WHEN a profile label is accepted THE SYSTEM SHALL normalize it, enforce a
+  bounded display length, and reject control characters and recognized
+  credential patterns before it can enter UI, MCP instructions, or sync.
+- [ ] WHEN the service mutates profile configuration THE existing loopback,
+  bearer-token, Host-header, and same-origin protections SHALL apply.
+- [ ] WHEN a profile label or id appears in logs or telemetry THE SYSTEM SHALL
+  treat it as local configuration metadata; the locked team telemetry schema
+  SHALL NOT be widened for this feature.
+
+### 5.8 Reliability, accessibility, and performance
+
+- [ ] WHEN a profile switch occurs in the app THE SYSTEM SHALL cancel or ignore
+  stale responses from the prior profile so its concepts cannot flash or remain
+  in the new view.
+- [ ] WHEN the service returns any profile-derived read or mutation response THE
+  SYSTEM SHALL include an immutable profile id plus manifest revision; the
+  renderer SHALL commit a multi-request load only when every response matches
+  the expected pair, and mutations SHALL require an explicit profile id and
+  revision precondition.
+- [ ] WHEN source initialization for one profile fails THE SYSTEM SHALL surface
+  the affected source and continue with the other layers under the existing
+  warn-and-continue policy; a malformed profile contract SHALL fail before any
+  source is opened.
+- [ ] WHEN 25 profiles and 100 project mappings are configured THE SYSTEM SHALL
+  select a profile without network access and without a user-perceptible delay.
+- [ ] WHEN the profile UI is used at supported desktop and narrow widths THE
+  SYSTEM SHALL remain keyboard operable, keep focus visible, avoid page-level
+  horizontal scrolling, and meet the project's WCAG AA target.
+
+### 5.9 Dogfood success gate
+
+- [ ] WHEN implementation is feature-complete THE team SHALL run a seven-day
+  trial with at least 30 recorded starts using at least three materially
+  different profiles and at least two AI harnesses, including at least five
+  starts per profile and ten per harness; failed starts SHALL remain in the
+  denominator.
+- [ ] WHEN a session starts inside a mapped project THE selected profile SHALL
+  be correct in 100% of recorded trial starts, with zero cross-profile reads,
+  cache hits, captures, or Pack assignments.
+- [ ] WHEN the trial ends at least 90% of mapped-project sessions SHALL require
+  no manual profile override, and the user SHALL be able to identify the active
+  app profile and agent-selected profile in under ten seconds.
+- [ ] WHEN trial friction is recorded THE next connector SHALL be chosen from
+  repeated missing-source evidence; Slack, Confluence, Google Drive, billing,
+  and marketplace work SHALL remain deferred until this gate passes.
+
+## 6. Out of Scope
+
+- Automatic source discovery or content ingestion from the entire filesystem.
+- Switching the profile of an already-running MCP process.
+- Combining multiple profiles in one answer or allowing cross-profile search.
+- Remote storage of project mappings, local paths, context content, or
+  integration credentials.
+- A hosted ContextCake MCP service.
+- Slack, Confluence, or Google Drive adapters.
+- New resolution rules, semantic retrieval, embeddings, or autonomous conflict
+  reconciliation.
+- Turning on billing, checkout, creator submissions, or marketplace claims.
+- Deleting source directories, repositories, caches outside ContextCake's own
+  cache root, local overlays, or retained Pack content as a side effect of
+  profile deletion.
+- Windows/Linux desktop UX in this release; core selection behavior remains
+  path-platform-aware and testable outside macOS.
+
+## 7. Open Questions and Resolved Defaults
+
+There are no blocking product questions in this draft. The following defaults
+are explicit so implementation does not silently invent them:
+
+| Question | Default |
+|---|---|
+| User-facing term | **Project profile**; shortened to **Profile** in compact UI |
+| Required fallback id | `default` |
+| New profile contents | Empty; copying another profile is a deliberate action |
+| Automatic routing signal | Longest canonical containing project folder |
+| Manual app selection | Affects the app only, not running MCP processes |
+| CLI override | `--profile <id>` wins over working-directory mapping |
+| Profile deletion | References only; never underlying user content |
+| Project-path sync | Never synced |
+| Active app profile sync | Never synced; remote activity is not an activation signal |
+| Source sharing | Each profile owns layer configuration; retained Pack files may be shared |
+| Ambiguous/invalid matched mapping | Fail closed rather than fall through |
+| Legacy migration trigger | First creation of an additional profile |
+| Transitional hybrid manifests | Preserve current flat behavior until atomic normalization |
+| Synced incomplete source metadata | Pending and non-runnable until local repair/trust |
+
+Changing a default that affects resolution, privacy, capture routing, or
+deletion safety requires a spec amendment.
+
+## 8. Dependencies
+
+- The existing flat-manifest resolver, MCP, and engine-service paths.
+- The approved Manifest v2 profile shape and selection order in
+  `specs/contextcake-integrations/spec.md`.
+- The Mac app's native folder picker, settings storage, bearer-protected engine
+  service, and optional safe settings sync.
+- The existing Pack registry and profile-aware CLI assignment fields.
+- The team-sync live-layer and capture contracts, extended from one flat stack
+  to one selected profile.
+- The GitHub source adapter work must be merged and its credential-injection
+  boundary retained before private GitHub repositories are offered in profile
+  setup. Project Profiles themselves remain usable with local Markdown and
+  ContextCake folders if that dependency ships later.
+
+## 9. Requirement Traceability
+
+This spec narrows and completes existing contracts rather than introducing a
+new architecture:
+
+- Integrations §5 supplies explicit → longest-prefix → default selection,
+  backward compatibility, and local credential custody.
+- Distribution design §5 supplies the local manifest and settings locations;
+  the active app profile is a preference, while mappings remain in the local
+  manifest.
+- Harness Connect supplies the single global MCP registration and verification
+  surface.
+- Packs supplies immutable installed versions, local overlays, and per-profile
+  assignments.
+- Team Sync supplies the one-live-layer rule, capture safety, and content-free
+  telemetry; this feature scopes all of them to the selected profile.