@omega.js/manager 0.1.0

package/docs/payment.md

@@ -0,0 +1,83 @@
+# The payment service — products, prices, and webhooks
+
+The `payment` service reconciles the brand's payment providers to `payment.products`: Stripe
+(account profile, products + prices, webhook, plus the two Dashboard-only guidance checks),
+PayPal (catalog products + billing plans, webhook), and Chargebee (item family → items → item
+prices, webhook). Product ids are written back into omega.json5 and mirrored in state.
+
+## What it reconciles
+
+**Stripe** — `stripe-account` (business profile diffed to brand config),
+`stripe-radar` and `stripe-disputes` (Dashboard-only, so: guidance + an interactive confirm),
+`stripe-webhook`, `stripe-products` (config id → state → metadata match → create; stale
+prices ARCHIVED, since Stripe cannot delete a price).
+
+**PayPal** — `paypal-account` (an auth probe that also resolves live vs sandbox),
+`paypal-webhook`, `paypal-products` (catalog products + billing plans; plans matched by
+interval + amount + trial-cycle presence, duplicates and stale plans deactivated, legacy
+products' active plans deactivated so no new subscription lands on them). A product with
+`trial.days` gets TWO plans per paid interval — the trial twin and the skip-trial twin,
+named `<Display> (Monthly)` and `<Display> (Monthly, no trial)` — because PayPal puts a
+trial on the PLAN, so a buyer who is not owed one needs a plan with no free cycle on it
+([#761](https://github.com/Omega-JS-Stack/omega/issues/761)). Neither twin is a duplicate
+or a stale copy of the other, so a rerun creates and deactivates nothing; a brand that
+already ships trials needs ONE manage run to mint the new twins.
+
+**Chargebee** — `chargebee-account` (an API-access probe), `chargebee-webhook`,
+`chargebee-products` (fully deterministic ids — family `{brandId}`, item
+`{brandId}-{productId}`, price `{brandId}-{productId}-{interval}` — so resolution needs no
+stored state at all: a 404 on the deterministic id means "create it").
+
+**Coinbase Commerce** — **nothing**, and that is the whole design
+([#642](https://github.com/Omega-JS-Stack/omega/issues/642)). A crypto charge is created ad
+hoc at checkout, so there is no catalog to reconcile, and its webhook endpoint is set by hand
+in the Coinbase dashboard (the API manages none). Its entire manage-time surface is the
+CREDENTIAL, which the setup contract asks for in `setup` — gated on
+`payment.providers.coinbase.enabled` being explicitly `true`, so a brand that never turned
+crypto on is never asked for a key it has no use for. `--provider=coinbase` therefore asks for
+the key and then skips, saying so.
+
+Every webhook operation matches by exact URL, deletes every OTHER endpoint on the brand's API
+host (stale twins — endpoints on other hosts are never touched), re-enables an endpoint the
+provider auto-disabled, and diffs the event set.
+
+## Config
+
+- `payment.enabled: false` — skip. The service also skips when `payment.products` has no paid,
+  non-archived entry.
+- `payment.products[]` — the SSOT. Free tiers have no prices; an archived product keeps its
+  provider objects but stops being reconciled.
+- `payment.products[id=…].{stripe,paypal}.productId` — written back on create/match.
+- `payment.providers.stripe.{publishableKey,updateAccountInfo,radar,radarConfirmed,disputesConfirmed}`,
+  `payment.providers.paypal.clientId`, `payment.providers.chargebee.site` — the public halves
+  live in config; each provider can be disabled with `payment.providers.<name>: false`.
+- `payment.providers.coinbase.enabled` — the exception, because Coinbase Commerce has NO public
+  half: its API key is the entire credential, so `enabled` (default OFF) is both the switch and
+  the opt-out, and the setup flow's "Disable permanently" lands `false` THERE rather than on the
+  provider block.
+- `brand.images.brandmark` — the product image the providers show (omega-manager hardcoded a
+  company CDN).
+
+**Credentials**: `STRIPE_SECRET_KEY`, `PAYPAL_CLIENT_SECRET`, `CHARGEBEE_API_KEY`,
+`COINBASE_COMMERCE_API_KEY` — each OPTIONAL (`gates: false`), so a missing Stripe key never
+gates a PayPal brand and each entry's "Disable permanently" writes only its own provider's
+`false` (coinbase's lands on `payment.providers.coinbase.enabled`). `OMEGA_WEBHOOK_KEY` is
+OMEGA's own and is minted, not asked for. `--provider=stripe|paypal|chargebee|coinbase`
+narrows a run to one provider's operations.
+
+## Gotchas
+
+- **A shared Firebase project has no `api.{domain}` backend** to receive events, so every
+  webhook operation is skipped there.
+- **Stripe account updates are not supported on every account type** (org sub-accounts): a
+  failed update warns rather than errors, and `payment.providers.stripe.updateAccountInfo:
+  false` turns the whole profile sync off.
+- **Radar rules and Enhanced Dispute Protection have no API.** They print the desired rules
+  plus a Dashboard deep-link and stay warned until confirmed; the confirmation is one of the
+  few reconcile flags config keeps ([#434](https://github.com/Omega-JS-Stack/omega/issues/434)).
+- **Chargebee does not return `enabled_events`**, so event drift cannot be diffed: events are
+  set on CREATE only, and changing them means delete + recreate.
+- **Chargebee has no daily billing cycle**, and its one-time `once` prices are not managed yet
+  (a visible note, not a silent skip).
+- **PayPal sandbox mode** reconciles the payments-QA fixtures, so the step closes with the
+  sandbox-buyer reminder.

package/docs/repo.md

@@ -0,0 +1,48 @@
+# The repo service — the brand's GitHub presence
+
+The `repo` service reconciles the brand's GitHub side: the org profile, the brand-monorepo
+repo, and GitHub Pages. It is the monorepo cousin of legacy omega-manager's github service,
+which managed one repo per target — here a brand is ONE repo.
+
+## What it reconciles
+
+- **`org`** — the org profile matches the brand: display name, support email
+  (`support@{domain}`), billing email, description (truncated to GitHub's 160-char org
+  limit), blog URL, and `location` only when configured. Skipped for a shared org.
+- **`repo`** — the repo exists with the right settings. Missing → created EMPTY (the brand
+  already exists locally; the user pushes to it — no template, no clone, that is onboarding's
+  job). Existing → visibility and homepage diffed, and only the drift is patched.
+- **`pages`** — GitHub Pages serves the website from `gh-pages` with `brand.url` as the
+  custom domain.
+
+## Config
+
+Everything lives under `repo.providers.github` in the brand `config/omega.json5`:
+
+| Key | Meaning |
+|---|---|
+| `org` | Repo owner (org or user). No default — unset and the service skips. |
+| `shared` | `true` = the org is shared with other brands, so the org-level `org` operation is filtered out: one brand must not rewrite a shared org's profile. |
+| `repo` | Optional `owner/name` slug or bare name. Name defaults to `<brand.id>-omega` (the `<brand.id>-<role>` rule, [#809](https://github.com/Omega-JS-Stack/omega/issues/809)), owner to `repo.providers.github.org`. |
+| `private` | Repo visibility (manager default `true`). |
+| `location` | Org profile location — only reconciled when set (omega-manager hardcoded a country). |
+
+The repo identity is pure derivation from config (`@omega.js/config`'s `brandRepoName` /
+`brandRepoOwner`, shared with `deploy --direct`), so nothing about it is persisted anywhere.
+
+## Credentials
+
+The `gh` CLI, authenticated — `gh auth login`, or a `GH_TOKEN`/`GITHUB_TOKEN` in the brand
+`.env` (loaded before services run; `gh` honors both). The client verifies `gh` is installed
+and authenticated at construction, and every invocation is `execFileSync` with an argv array
+— no shell, so brand-config values can never inject commands. The service declares no entry
+in the `REQUIRES` registry because it authorizes through `gh`, not through a key.
+
+## Gotchas
+
+- **A missing `gh-pages` branch is not an error.** It appears with the first deploy; the
+  operation says "deploy the website first" and moves on.
+- **An owner that is a user, not an org**, makes the `org` operation inapplicable — noted,
+  not failed.
+- **One Pages site per repo.** Legacy per-subdomain Pages repos (`{brand}-{sub}-website`)
+  have no monorepo equivalent; multi-site hosting rides the edge/hosting story instead.

package/docs/search.md

@@ -0,0 +1,44 @@
+# The search service — the Search Console property
+
+The `search` service owns the brand's Google Search Console presence: the `sc-domain:{domain}`
+domain property (which covers every subdomain), verified by a DNS TXT record written through
+Cloudflare, plus sitemap submission and the GA-association nudge. It runs after `edge` (the
+zone must exist for TXT verification) and after `analytics` (the GA property is what the
+association points at).
+
+## What it reconciles
+
+- **`property`** — an existing property is converged proof, nothing else to check. A missing
+  one is created in ONE pass: fetch the DNS_TXT verification token (idempotent — Google returns
+  the same token until it is used), write the TXT record via Cloudflare (a stale
+  `google-site-verification` record at the same name is replaced), then verify. Interactive
+  runs poll until DNS propagates; non-interactive and dry runs attempt verification once,
+  report warned, and the rerun converges.
+- **`ga-link`** — the Search Console ↔ GA4 association. There is NO API on either side, so it
+  is instructions plus an interactive confirm, warned until confirmed; the confirmation lands
+  at `search.providers.searchConsole.gaLinked`
+  ([#434](https://github.com/Omega-JS-Stack/omega/issues/434)) so the next run believes it.
+- **`sitemaps`** — submits only what is MISSING. Legacy omega-manager resubmitted every
+  sitemap on every run, which made a converged brand mutate forever; Google re-crawls
+  submitted sitemaps on its own.
+
+## Config
+
+| Key | Meaning |
+|---|---|
+| `search.providers.searchConsole.enabled: false` | Skip the service. |
+| `search.providers.searchConsole.sitemapPaths` | Paths to submit (default `/sitemap.xml`). |
+| `search.providers.searchConsole.submitSitemap: false` | Turn sitemap submission off. |
+| `search.providers.searchConsole.gaLinked` | The one-time GA-association confirm. |
+| `analytics.providers.google.propertyId` | Read (not written) by `ga-link` — no property, nothing to associate. |
+
+**Credentials**: `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET`, scopes `webmasters` and
+`siteverification`, on the ONE shared token store (`.omega/auth/google-tokens.json`) beside
+the cloud grant. `CLOUDFLARE_TOKEN` is optional: without it the property operation prints the
+TXT record to add by hand.
+
+## Gotchas
+
+- **A brand with no web target has no sitemap to submit** — skipped, not warned.
+- **Verification happens once.** Google answers "already verified" when an earlier attempt
+  succeeded; that is treated as success, not an error.

package/docs/seo.md

@@ -0,0 +1,34 @@
+# The seo service — parasite SEO repos
+
+The `seo` service creates and maintains parasite SEO content: programmatically created GitHub
+repos with templated READMEs, download scripts, and a maintenance workflow. It sits late in
+the walk — low priority, no downstream dependencies.
+
+## What it reconciles
+
+One operation, `github-repos`, per configured item: create the repo when missing (public,
+auto-init README), push the generated + static template files (content-compared, so an
+unchanged file is never rewritten), delete stale non-template files, reconcile description /
+homepage / topics, and star the repo as the author.
+
+## Config
+
+Content lives at `seo.github.content[]` in `config/omega.json5`, or in a `config/seo.json5`
+sidecar whose keys merge OVER the config's `seo` section (the `chatsy.md` / `replyify.md`
+convention: big content sections get their own file). `seo.enabled: false` skips the service,
+and no content at all is a clean skip — this service never WRITES config, so nothing is
+auto-created for a brand that declared nothing.
+
+Per item, `author.token` (`env:VAR_NAME` or a literal) overrides the `gh` auth for that item's
+API calls, and `author.git` rides the Contents API commits as author and committer — parasite
+repos owned by separate accounts.
+
+**Credentials**: the default `gh` CLI auth, plus those per-item author overrides.
+
+## Gotcha: the collision guardrail
+
+A parasite repo this handler created contains only the template's files, so before ANY write
+the existing tree is inspected: more than ten non-template ("stale") files means the configured
+name collides with a REAL repo, and the item ERRORS without touching anything. Legitimate
+parasite repos sit at zero to two stale files after a template change. **Never reuse a real
+repo's name for a parasite entry.**

package/docs/server.md

@@ -0,0 +1,37 @@
+# The server service — the brand's entry in the company registry
+
+The `server` service publishes the brand's registry entry to the COMPANY server's Firestore at
+`brands/{brand.id}`. The company's parent backend keeps a registry of every brand it serves —
+webhook fan-out and cross-brand features read it — and this keeps that entry in sync with the
+brand's config. It is a company-server OPERATOR service: every other brand answers "Disable
+permanently" once.
+
+Its sibling is the [directory](directory.md) service, and the difference is deliberate: the
+registry here is a full REPLACE of the framework's document, the directory is a MERGE into a
+document a hub also writes.
+
+## What it reconciles
+
+One operation, `brands`. Only three top-level config sections cross into the registry —
+`brand`, `repo`, `sponsorships` — and the document is fully REPLACED on write, so a key
+removed from config disappears from the registry too. The write is diff-synced: the current
+document is read first and only drift is written (omega-manager overwrote it blindly on every
+run, with no dry-run guard). Equality is structural and key-order-insensitive, because a
+full-replace write makes ANY difference — including an extra key in the current document —
+drift.
+
+## Config and credentials
+
+- `server.enabled: false` (or `server: false`) — skip.
+- The entry id is `brand.id`.
+
+`SERVER_SERVICE_ACCOUNT` in the brand `.env` — a path to the company server's Firebase
+service-account JSON, absolute or relative to the brand root. The service account names the
+target project; omega-manager hardcoded the company project instead and read its secrets from
+the company-instance `.output/` tree.
+
+## Gotcha
+
+Because the write is a replace, anything a human adds to a registry document by hand is
+removed on the next walk. Content the framework does not own belongs on a different document —
+or in the directory entry, whose write is masked.

package/docs/shared/agent-docs.md

@@ -0,0 +1,89 @@
+# Brand agent-docs chain (AGENTS.md / CLAUDE.md)
+
+**The problem**: every brand needs current framework guidance for AI agents, but copying it into each brand drifts. **The design (Ian 2026-07-20, amended 2026-07-27)**: every brand reads the SAME entry the monorepo uses — the top-level omega `AGENTS.md`, the map — and the map's pointers (plus the omega plugin's hooks) orchestrate which docs load. The brand-root knowledge itself lives in `docs/manager/brand.md`; no AGENTS.md anywhere carries content.
+
+## The chain
+
+```
+brand/CLAUDE.md            @AGENTS.md                          (one line, Claude Code's entry)
+brand/AGENTS.md   line 1:  @node_modules/@omega.js/AGENTS.md  (the top-level omega map — see below)
+                  below:   `# <brand> — brand notes` + the brand's own notes — NEVER touched by the framework
+```
+
+`node_modules/@omega.js/AGENTS.md` is a SYMLINK the workspace service maintains: it resolves the framework monorepo through the installed manager package's real path and links straight at the live top-level map. It sits in the scope directory — no package in the path — because the map belongs to the ecosystem, not to any one package. A published install has no monorepo above the package, so the link lands on the map prepare vendored INTO it (`@omega.js/manager/docs/AGENTS.md`, below). The two candidates are tried in that order, live map first, so a locally linked brand never lands on the generated copy sitting in that same monorepo's `packages/manager` ([#144](https://github.com/Omega-JS-Stack/omega/issues/144)).
+
+(The cp244 marker comment under the import was culled — Ian 2026-07-20: keep it short. Heals no longer scrub legacy copies (#148): a leftover marker or retired import line is consumer content, removed by hand per [breaking-changes.md](breaking-changes.md).)
+
+- The import path is **relative** (portable to any machine). For hoisted installs (the in-repo test brands are npm workspaces of this monorepo) the ensure step walks up and writes the correct depth, e.g. `@../../node_modules/@omega.js/AGENTS.md`.
+- The service resolves the monorepo through the installed manager package's real path (the local-era `file:` symlink), so the link always lands on the LIVE top-level map — framework edits are instantly visible to every brand session.
+- Non-Claude agents read `AGENTS.md` but don't follow `@` imports — the import line itself names the target path for them.
+
+## Maintenance
+
+`npm run manage` (the manage cycle's `workspace` service, `agents` op — `packages/manager/src/services/workspace/ensure/agents.js`, logic in `src/lib/agents-md.js`):
+
+| State found | Action |
+|---|---|
+| No `AGENTS.md` | Created: import + brand-notes skeleton |
+| Import present at line 1 (right depth) | No-op |
+| Import missing / not first / stale depth | Healed: resolved import moved to line 1, duplicates removed, consumer content preserved verbatim |
+| No `CLAUDE.md` | Created as the one-line `@AGENTS.md` pointer |
+| `CLAUDE.md` carries content | WARNED (never clobbered) with the move-it-to-AGENTS.md message |
+
+Pinned by `packages/manager/test/agents-md.test.js` (no package agent docs + files whitelist, guide-link create/heal/skip against both the local-era and published-install shapes, path resolution, create/heal/idempotence, content preservation).
+
+## Published packages carry their own docs ([#64](https://github.com/Omega-JS-Stack/omega/issues/64))
+
+A consumer install has no monorepo to point at, so the prepare lane ships the knowledge INSIDE each publishable. The devkit vendor hook every framework already runs (`packages/devkit/tools/vendor-docs.js`, called from `tools/vendor.js`) copies, for `@omega.js/{backend,client,desktop,extension,manager,web}`:
+
+| Monorepo source | Shipped as | Notes |
+|---|---|---|
+| `docs/<package>/` | `<package>/docs/` (flat) | The guide lands at `docs/index.md`, beside the package's committed deep docs; nested dirs (`classy-v2/`) survive |
+| `docs/shared/` | `<package>/docs/shared/` | The cross-framework contracts, verbatim |
+| `AGENTS.md` (the repo-root map) | `manager/docs/AGENTS.md` | Manager ONLY — the target the brand chain's scope symlink lands on when there is no monorepo. Links retargeted (see below) |
+| `agent-plugins/claude/` | `manager/claude-plugin/` + `manager/.claude-plugin/marketplace.json` | Manager ONLY — the plugin every brand enables (see below). `.mcp.json` ships WITH it: since [#144](https://github.com/Omega-JS-Stack/omega/issues/144) it launches `mcp-router-launch.js` inside the plugin, which node-resolves `@omega.js/mcp-router` from the install around it (a real dependency of the manager) instead of addressing the monorepo tree |
+
+The guide's monorepo-relative links are rewritten to the shipped layout on the way in (`../../packages/<self>/` → `../`, `../shared/` → `shared/`), so `docs/index.md` still reaches the package's deep docs, its README, and the shared contracts. Cross-framework links (`../backend/index.md`) are left verbatim — another framework's guide isn't in this tarball.
+
+The map's links are repo-root-relative, so it gets its own pass (`rewriteMapLinks`): `docs/shared/<x>.md` → `shared/<x>.md`, `docs/manager/<x>.md` → `<x>.md` (the manager's guide tree lands flat in the same dir), `docs/<other>/<x>.md` → `../../<other>/docs/<x>.md` (a sibling package under the same `@omega.js` scope), and a `packages/…` or `brands/…` link keeps its words while losing the link — no published target exists. A sibling that never publishes (`devkit`) or isn't installed leaves a dead relative link, the same trade the guide trees already make.
+
+Everything written is GENERATED: gitignored per package, cleared before each rewrite, and pinned by `packages/devkit/test/vendor-docs.test.js` (fixture monorepo) plus `scripts/vendor-docs.test.js`, which packs all six documented packages for real and reads the tarball listings.
+
+Version-matched by construction: the docs in `node_modules/@omega.js/web/docs/` are the docs of the version installed there.
+
+## Brands enable the plugin from their installed manager ([#62](https://github.com/Omega-JS-Stack/omega/issues/62))
+
+The plugin rides in `@omega.js/manager` because that is the package every brand installs. The workspace service's `claude-settings` op writes/heals the brand's committed `.claude/settings.json`:
+
+```json
+{
+  "extraKnownMarketplaces": { "omega": { "source": { "source": "directory", "path": "./node_modules/@omega.js/manager" } } },
+  "enabledPlugins": { "omega@omega": true }
+}
+```
+
+Committed, so every collaborator's session in that brand loads the omega skills and hooks — a directory marketplace is read LIVE from that path, so `npm update` moves the plugin with the package. The op only fires on a PUBLISHED install: `node_modules/@omega.js/manager` must carry the vendored `.claude-plugin/marketplace.json` **and** be a real directory. A locally linked brand's manager is a SYMLINK into the monorepo — whose `packages/manager` grows that same generated marketplace on every prepare — so the link itself is the local-era signal and the step skips; the developer's own user-scope install covers those sessions. The brand file NEVER points at a monorepo path — it would be machine-specific.
+
+Once loaded, the plugin's hooks make the chain BINDING in that brand: the inject hook discovers every target the brand declares and asks for each one's skill plus this map as required reading, and the gate hook refuses a write under `targets/<t>/` or to `config/omega.json5` until the skill owning that surface has been invoked. Mechanics and the surface table: [the plugin README](../../agent-plugins/claude/README.md).
+
+The gate reads the same way for a human's chat and for an agent that has no Skill tool, through two lanes and no others ([#760](https://github.com/Omega-JS-Stack/omega/issues/760)). In the main chat, invoking the skill IS the record. A subagent that writes its files through Bash reads the guide its brief names and then runs the one sanctioned command, `agent-plugins/claude/hooks/gate/mark.sh <skill>` here (in a brand: `node_modules/@omega.js/manager/claude-plugin/hooks/gate/mark.sh`), which writes the marker the hook would have written. A hand-written marker is a process breach, not a shortcut. Both lanes, and the flags: [the plugin README](../../agent-plugins/claude/README.md).
+
+Reading the chain is one half; acting on it is the other. The guard hook holds the other half in the same brand: a `Write|Edit` to a framework-owned file is refused with the upstream-first message ([#452](https://github.com/Omega-JS-Stack/omega/issues/452)). Generated and vendored files — `node_modules/`, any `dist/`, a generated header, the OMEGA-managed `database.rules.json` — are hard-refused and name the real source to edit; a SHADOW COPY, a brand file whose path mirrors a file the installed framework ships through its override layer (read from `node_modules/@omega.js/<framework>/`, never a hardcoded list), is refused with the two exits: file the framework issue, or declare the override with `omega:consumer-override: <reason>` in the file's first five lines (`omega customize` writes that marker itself, so a materialized file passes as it lands). Only the override MECHANISM is guarded: a brand's pages are content and its documented entry files are its own, so neither is ever refused. The monorepo is exempt and everything unrecognized fails open. The lookup-root table and the class rules: [the plugin README](../../agent-plugins/claude/README.md).
+
+## Packages carry no agent docs (Ian 2026-07-27)
+
+No `packages/<pkg>/` has an `AGENTS.md` or `CLAUDE.md` — deleted outright, no exceptions. Monorepo sessions get the map from the parent walk; consumer brands get it through the maintained scope symlink; a standalone package install has no resolvable chain anyway; the publish era generates whatever a shipped package needs ([#64](https://github.com/Omega-JS-Stack/omega/issues/64)).
+
+## The one deliberate gap
+
+- **`brands/sandbox-brand` carries NO agent-docs chain.** It is a synthetic fixture the automated corpus/e2e runs mangle and reset — nothing durable lives there, so nothing agent-facing is written there.
+
+## Editing the guide
+
+The brand-root guide is [docs/manager/brand.md](../manager/brand.md) — framework-owned, brand-agnostic (structure, verbs, per-target required-reading pointers, hard rules). Brand-specific knowledge belongs below the import in that brand's own `AGENTS.md`.
+
+## Per-target docs — RETIRED in brand context (cp246)
+
+Per-target `AGENTS.md`/`CLAUDE.md`/`CHANGELOG.md`/`docs/` scaffolds predate the brand-monorepo era; Claude Code walks parent directories, so the brand-root chain covers target-dir sessions. The shared defaults engine now has a `retire` fileMap rule (devkit `defaults-engine.js`), wired mirrored in all four frameworks' brand branches (detection = the existing `@omega.js/config` brand-root resolution): in a brand target those files NEVER scaffold; an existing framework-owned-only copy (Custom section empty/whitespace or byte-equal to the shipped boilerplate; marker-less files must equal the rendered template) is deleted once, loudly; a copy carrying real consumer content is preserved with a move-it-to-the-brand-root warning. Standalone projects keep full per-project doc scaffolding, and it follows the same shape as a brand root (#63): the framework template is an `AGENTS.md` (marker-merged, so consumer notes below the Custom marker survive every setup) beside a one-line `@AGENTS.md` `CLAUDE.md` pointer. Test-pinned both ways.
+
+**Prior-generation files ([#101](https://github.com/Omega-JS-Stack/omega/issues/101)).** A destination carrying the OMEGA section markers when the current template no longer does is a file an EARLIER generation of the same framework generated — the pre-#63/#91 content-bearing `CLAUDE.md` against today's one-line pointer. Its markers are the framework's own signature, so the engine treats it as framework-owned on both paths: the brand branch retires it (instead of keeping it behind a false "carries consumer content" warning), and on the standalone upgrade path `overwrite: false` still heals it to the current template (instead of leaving a stale doc beside the new `AGENTS.md`). A file with no markers is judged as before — consumer-authored unless it equals the rendered template.