@omega.js/extension 0.1.0 → 0.50.0

package/docs/shared/publishing.md

@@ -1,9 +1,11 @@
 # Publishing — the runbook
 
-> The publish-proving checkpoint's script. Nothing here runs without Ian's explicit GO
-> (standing rule: zero npm publishes / GitHub releases until then). The latch is
-> mechanical: all seven publishables carry `private: true` — npm itself refuses until
-> the unlatch step below.
+> The publish-proving checkpoint's script, run for real on 2026-09-09: the seven
+> publishables are on the registry ([#25](https://github.com/Omega-JS-Stack/omega/issues/25)) at 0.50.0, the
+> monorepo's own number (0.1.0 went out first that night and is deprecated: the family
+> carries ONE version, the root package.json's, by ruling 2026-09-10),
+> each with `publishConfig.access: public`, and published is the new normal. The unlatch
+> step below is history; versions move by changesets from here.
 
 ## What publishes, what never does
 
@@ -22,8 +24,9 @@ installable beside it — a real dependency, never vendored. It ships no docs tr
 plugin's launcher can deep-resolve `@omega.js/mcp-router/bin/mcp-router.js`.
 
 Registry-real internal ranges (everything else is workspace `*`): `@omega.js/client`
-`0.1.0` in backend/web/desktop/extension; `@omega.js/backend` and `@omega.js/mcp-router`
-`0.1.0` in manager — EXACT, not carets, because the family is lockstep (below).
+in backend/web/desktop/extension; `@omega.js/backend` and `@omega.js/mcp-router` in
+manager — the EXACT family version (0.50.0 today), not carets, because the family is
+lockstep (below).
 
 ## Lockstep — the family ships ONE version ([#794](https://github.com/Omega-JS-Stack/omega/issues/794))
 
@@ -151,19 +154,18 @@ circumventing license-key functionality and removing notices.
    `VENDORABLE_PACKAGES` in [packages/devkit/tools/vendor.js](../../packages/devkit/tools/vendor.js)
    names them, so the list is never re-typed here).
 2. **Publish** each (changesets is configured lockstep + `access: public`, so the
-   seven go out at ONE number; for the FIRST 0.1.0 the direct form per package is
-   equally fine):
+   seven go out at ONE number; the direct form per package is equally fine):
    `npm publish --workspace=packages/<name>` — order matters only where a dependent
    waits on a dependency: **client and backend before their dependents**
    (web/desktop/extension need client on the registry; manager needs backend and
    mcp-router). Safe order: client → backend → mcp-router → extension → desktop →
-   web → manager. 2FA/OTP prompts surface here on first publish.
+   web → manager.
 3. **Verify from the outside**: in an empty temp dir, `npm install @omega.js/web`
    (and one more, e.g. manager) — install + `require.resolve` must succeed with no
    overrides. That is the moment the untested-lane risk is retired.
-4. **Flip omega-brand to registry specs**: from the brand root,
-   `npx omega i live` — tree-wide `file:` → the EXACT `0.1.0` pin + one registry
-   install (`restoreRegistrySpecs` writes the linked copy's version with no
+4. **Flip omega-brand to registry specs**: from any TARGET root (`targets/website`;
+   the manager has no `i` verb), `npx omega i live` — tree-wide `file:` → the EXACT
+   family pin + one registry install (`restoreRegistrySpecs` writes the linked copy's version with no
    caret, because the family is lockstep; `omega i local` is the way back for
    local-era work). Commit the brand's manifest+lock change.
 5. **Brand proof**: brand `npm run manage` (manage cycle) + a website build — the brand
@@ -178,6 +180,8 @@ circumventing license-key functionality and removing notices.
   changes bump minor and consumers move deliberately. A BRAND floats nothing: the
   manager pins every target exactly, so `omega update` is the one thing that moves
   a brand, and it moves the whole family ([updates.md](updates.md)).
-- 1.0.0 is a later, deliberate graduation (Ian's call), not an accumulation.
+- **1.0.0 is NEVER published without Ian's explicit word** (ruling 2026-09-10): it is the
+  official release, and it waits until OMEGA has survived on its own with Ian's brands.
+  Every number below it is free to publish whenever he wants.
 - The publish is also the brand-CI-build unlock: no tarball vendoring exists by
   design — the registry is the lane CI installs from.

package/docs/shared/updates.md

@@ -31,8 +31,8 @@ Only rows needing attention print; a fully-current tree reports one line. Rows s
 ## The @omega.js family is pinned, and `omega update` is its ONE mover ([#794](https://github.com/Omega-JS-Stack/omega/issues/794))
 
 Every `@omega.js/*` spec the manager writes into a brand is an EXACT pin, never a
-caret: `"@omega.js/manager": "0.1.0"` at the brand root, `"@omega.js/<framework>":
-"0.1.0"` in each target, all at the manager's own version (the family ships
+caret: `"@omega.js/manager": "0.50.0"` at the brand root, `"@omega.js/<framework>":
+"0.50.0"` in each target, all at the manager's own version (the family ships
 lockstep — [publishing.md](publishing.md)). A caret would let one target float
 ahead alone on somebody's `npm update`, which is how a brand ends up serving two
 copies of `@omega.js/client` and validating one omega.json5 with two validators.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@omega.js/extension",
-  "version": "0.1.0",
+  "version": "0.50.0",
   "description": "OMEGA extension framework — build, test, and package Chrome/Firefox extensions (MV3)",
   "private": false,
   "publishConfig": {
@@ -140,7 +140,7 @@
     "minimatch": "^10.2.5",
     "node-powertools": "^3.0.0",
     "sass": "^1.100.0",
-    "@omega.js/client": "0.1.0",
+    "@omega.js/client": "0.50.0",
     "wonderful-fetch": "^2.0.5",
     "wonderful-version": "^1.3.2",
     "ws": "^8.21.0",