docs: prepare OSM adoption and native host setup

VERSION

@@ -1 +1 @@
-0.1.20
+0.1.22

VISION.md

@@ -1,6 +1,6 @@
 # Vision
 
-Revision: 0.1.4 · Updated: 2026-10-09
+Revision: 0.1.21 · Updated: 2026-10-23
 
 Help an owner turn ideas, bugs, features, research and scoped defensive work into
 well-founded decisions and verified application changes, with less coordination
@@ -26,7 +26,8 @@ chat relay or scheduler. Use a maintained native capability first.
 Keep setup portable and testable. A feature earns its place through an observed
 problem and useful proof. Preserve application conventions instead of forcing
 every project into identical labels, technology, documentation or workflow.
-The package operates without AIOS or personal context.
+The package operates without The Onlinesourdough Method (OSM, formerly AIOS) or
+personal context.
 
 Success is useful decisions and verified deliveries on real applications,
 with observable human effort, rework and usage. Source checks and model claims

agent-ops/factory-agent-ops/SKILL.md

@@ -3,8 +3,8 @@ name: factory-agent-ops
 description: Act as a project's lead for ideas, research, accepted tasks or an approved backlog; coordinate native workers, independent review and authorized delivery.
 license: MIT
 metadata:
-  version: "0.1.18"
-  updated: "2026-10-17"
+  version: "0.1.21"
+  updated: "2026-10-23"
 ---
 
 # Factory Agent Ops

agent-ops/factory-agent-ops/references/t3.md

@@ -1,14 +1,24 @@
 # Operating through T3 Code
 
-Revision: 0.1.17 · Updated: 2026-10-15
+Revision: 0.1.21 · Updated: 2026-10-23
 
 Use the tools actually exposed by the installed T3/provider versions. This guide
 was written for **0.0.46-nightly.20261009.2861** (V2), with upstream source checked
-on 2026-10-09; its earlier guidance and proof remain 2861 observations. The current
-setup baseline is **0.0.46-nightly.20261009.2873**: the model target, option and
-runtime-mode guidance below comes from 2873 source and 2873 native readbacks.
-Stable 0.0.45 does not supply this orchestration surface. Source inspection does
-not qualify an installation; record native proof separately.
+on 2026-10-09; its earlier guidance and proof remain 2861 observations. The setup
+baseline it was qualified on is **0.0.46-nightly.20261009.2873**: the model target,
+option and runtime-mode guidance below comes from 2873 source and 2873 native
+readbacks. At that time stable 0.0.45 did not supply this orchestration surface;
+that is a historical observation, not a verdict on later stable releases. Source
+inspection does not qualify an installation; record native proof separately.
+
+Keep four states apart: dated native proof, functions released upstream, what
+this installation actually runs, and what it enforces and has accepted. A released
+function is not installed, and an installed one is not accepted until it works
+here. The live roadmap of released and pending native functions is
+[Factory #32](https://github.com/arcitai/factory/issues/32); stable-channel adoption
+and its maintenance gates are [Factory #34](https://github.com/arcitai/factory/issues/34).
+Wait for an official release instead of building a runtime, approval service,
+monitor or bridge for a missing function.
 
 ## The operator thread
 
@@ -80,10 +90,13 @@ The official [Claude](https://code.claude.com/docs/en/hooks) and
 `PermissionRequest` and direct MCP-tool hooks; Claude also documents `Notification`
 with `permission_prompt` and HTTP hooks. These are candidate signals, not
 installed or qualified here. The actual launch's setting sources, any SDK
-override and the exact mapping to a T3 request still need qualification. Missing
-parent wait notifications are tracked upstream in
-[t3code #15082](https://github.com/pingdotgg/t3code/issues/15082); add to it rather
-than filing another issue. Only a holder already authorized for that decision
+override and the exact mapping to a T3 request still need qualification. The
+closed [t3code #15082](https://github.com/pingdotgg/t3code/issues/15082) about
+missing parent wait notifications is historical; the remaining upstream gaps are
+linked from Factory #32. A notification, or the identity of a pending approval on a
+delegated wait, never confers authority to decide another worker's approval. An
+outside-agent MCP route with a writable mode spans the environment's projects; it
+is not a per-project access list or an approval grant. Only a holder already authorized for that decision
 may answer, after freshly checking the environment, project, thread, run, request,
 full input and live callback. Never late-approve an aborted or resolved request.
 Report one concrete handoff instead of polling or auto-confirming, then follow it

docs/architecture.md

@@ -1,6 +1,6 @@
 # Responsibility and access
 
-Revision: 0.1.20 · Updated: 2026-10-22
+Revision: 0.1.21 · Updated: 2026-10-23
 
 Factory has three responsibilities around existing tools. It has no server,
 provider adapter, task database or application runtime of its own.
@@ -89,6 +89,22 @@ runtime. A role instruction cannot provide that guarantee under a shared account
 The [setup guide](../foundation/factory-foundation/references/setup.md#least-privilege-in-practice)
 contains the native configuration and expansion procedure.
 
+Before choosing an isolated runtime, compare a rootless container and a VM against
+the same requirements, with the whole T3 execution server and its host-side tools
+inside the boundary; see [choose the boundary](../foundation/factory-foundation/references/setup.md#1-choose-the-boundary).
+Keep features in the installed T3, released or proposed upstream work, and
+boundaries the installation enforces as three separate statements. Shared threads,
+worktrees, environment labels and approval screens are not enforced isolation.
+Factory adds no runtime or policy engine to fill a gap; it waits for official
+native functions. The live roadmap of those functions and the comparison is
+[#32](https://github.com/arcitai/factory/issues/32), and stable-channel adoption
+for the Factory host is [#34](https://github.com/arcitai/factory/issues/34).
+Released upstream, installed here and accepted here are different states.
+The hosted platform in [#75](https://github.com/arcitai/factory/issues/75) is parked
+future product, not part of the reusable method; a project-specific extension
+needs its own mandate. Cloudflare in [#79](https://github.com/arcitai/factory/issues/79)
+stays optional research, not a required boundary or selected service.
+
 ## Sources kept by this package
 
 | Need | Canonical source |

docs/qualification.md

@@ -1,6 +1,6 @@
 # Qualification
 
-Revision: 0.1.20 · Updated: 2026-10-22
+Revision: 0.1.22 · Updated: 2026-10-23
 
 This record distinguishes source review, disposable exercises and observed native
 operation. A package release does not qualify another host, every future update
@@ -10,6 +10,8 @@ remain with the installation; public issues track the remaining acceptance work.
 | Boundary | Observed evidence | Limit / next check |
 | --- | --- | --- |
 | Package | Portable skills (nine from 0.1.20, with `factory-entry`; eight before), metadata/link checks and staging tests | Mechanical checks do not establish agent decisions |
+| OSM prerelease provenance (0.1.22 candidate) | 2026-10-23: the lead read the public GitHub API without authentication. The canonical repository is [onlinesourdough/OSM-plugin](https://github.com/onlinesourdough/OSM-plugin). [PR #80](https://github.com/onlinesourdough/OSM-plugin/pull/80) is merged, and [v0.30.0](https://github.com/onlinesourdough/OSM-plugin/releases/tag/v0.30.0) was published as a prerelease whose tag is that merge commit (`314dcf17`). Package CI passed on the PR's head commit. The tagged source declares 22 shared skills, and Codex and Claude select `osm@online-sourdough`. The lead also checked the pinned installation and migration documents against their Git blobs. The migration guide now names the canonical repository and this prerelease, links the pinned documents, and orders the cutover: install the new selector, disable the old active source before fresh-session acceptance, and retire the disabled registration only afterwards. Source candidate only | This is public metadata, not use. It is a prerelease, not stable. CI ran on the PR head, not on the tag commit. No Factory host or caller was observed adopting it, and none was authorized to; a peer's reported native use and a separate preview pull request were not verified or selected here. Working AIOS 0.29 calls stay on each host until that host qualifies its own cutover. OSM #62, #77 and #76 remain open with their owners. Package checks and independent review of this candidate are pending |
+| Optional method migration and native host baseline (0.1.21 candidate) | 2026-10-23: [Factory #93](https://github.com/arcitai/factory/issues/93) source change after the owner renamed AIOS to The Onlinesourdough Method (OSM) ([OSM #76](https://github.com/onlinesourdough/AIOS-plugin/issues/76)). Foundation gains a guide to migrating an optional method package by generation, with a baseline record, cutover gates, per-host outcomes and rollback. Current Factory references to the method now use the new name; provenance and past evidence keep AIOS. The setup guide now prefers the official stable T3 channel, keeps installed, upstream and enforced boundaries apart, and compares a rootless container with a VM for the whole execution server, linking the live roadmap in [#32](https://github.com/arcitai/factory/issues/32) and [#34](https://github.com/arcitai/factory/issues/34). On the first candidate (`27ce6d0`), after earlier equipment failures that are retained, the package check passed with 9 skills and 0 errors, 16 unit tests passed, and all-set staging produced 9 skills and 29 manifest-bound files. One fresh source-method exercise applied each of five synthetic packets once: four adoption cases matched the parent's rubric; the boundary case was partial, because it followed the guide's then-opening preference for a VM before the comparison, though it kept every no-effect and recovery gate. The exerciser ran one `pwd` outside its original reader restriction, disclosed in its record. A correction then made the boundary compare-first and reconciled the guides with #32, #34, #75 and #79. Its independent source review applied one new synthetic boundary decision, which selected neither option before matched evidence, and requested one more correction: the migration guide's recovery copy could be stale by the time affected work reached its idle checkpoint. The guide now makes or freshly verifies a consistent current copy at that checkpoint, before any effect. Source candidate only | The second independent review round returned ACCEPT for that recovery correction; see [PR #94](https://github.com/arcitai/factory/pull/94). No host was migrated and no installation, configuration or path changed; existing AIOS calls stay current until the native OSM candidate ([OSM #62](https://github.com/onlinesourdough/AIOS-plugin/issues/62)) is qualified and distribution ([OSM #77](https://github.com/onlinesourdough/AIOS-plugin/issues/77)) is verified. Power BI and other owner consumers outside this host remain unknown. No container, VM or stable-release trial was run, and the Factory host's T3 update remains held by #34 |
 | Owner entry and all-skill staging (0.1.20 candidate) | 2026-10-22: [Factory #91](https://github.com/arcitai/factory/issues/91) source change, after an owner-side planning agent sent application work to the Factory repository's AgentOps as if it were Factory's general entry. That agent had no Factory skill enabled (owner report, not reproduced here). Adds the `factory-entry` skill, an `all` mode for the existing stage helper, and setup guidance for installing, discovering and using the entry. Portable skills and staging were chosen; plugin packaging stays optional. On the candidate, the package check passed with 9 skills and 0 errors, and 16 unit tests passed. All-set staging from the frozen source snapshot produced 9 skills and 28 manifest-bound files. Source candidate only; not delivered, released or installed | See the delivery PR for representative caller outcomes and independent review of the exact candidate. Installation, discovery and use in the owner's active caller have not been run; staging installed nothing |
 | Host continuity and maintenance (0.1.19 candidate) | 2026-10-21: [Factory #83](https://github.com/arcitai/factory/issues/83) source change, after an installation could look ready while operator apps did not start after login and no maintenance schedule was active (owner report, not reproduced here). Setup, adoption and architecture now describe the optional host coordinator, separate startup stages, one owned nightly maintenance opportunity, scoped holds and a same-host recovery copy. The existing owner coordinator reported one actual scheduled wake on 2026-10-21. On the frozen candidate: `scripts/check.py` passed with 8 skills and 0 errors, 11 unit tests passed, and staging Foundation produced its 9 portable files plus a manifest, which were not installed. In a fresh Sol 6.1 Max context, one application each of four synthetic cases matched the retained rubric (lead assessment, evidence kept privately): independent source work continued without a hold; a startup or wake was kept apart from recovery; unknown local account-tool exposure stayed unknown; and a real maintenance hold kept its timeouts and restored prior states. An earlier rehearsal was not run, because its brief prohibited the available reader; it is neither a pass nor a failure | These are bounded synthetic decisions, not live proof of boot, update, reconnect or isolation, and not a reliability result. That single wake is not proof of reboot, of operation with the Mac disconnected, or of full recovery. Controlled reboot, login and reconnect, safe update and continuation, and the host gates remain open live acceptance; this change marks none of them complete. Independent review of the exact final source is pending in the delivery PR |
 | Production artifact evidence (0.1.18 candidate) | Reconciled 17 October 2026 from product-lead handbacks ([Factory #76](https://github.com/arcitai/factory/issues/76); not reproduced here). OPD: the source expected eight embedded editor assets, but the installed executable held six and served editor-not-built. Its six tests substituted a `#[cfg(test)]` `tests::BUNDLE_FILES` list, while production uses `OUT_DIR/bundle.rs`, so those tests did not exercise production inclusion. The OPD lead's original handoff left a production smoke optional; the corrected R10 proof gate made it required. A same-source replacement was atomically adopted at 06:17:35Z (transferred receipt). AIOS: the contrast build installed at 06:18:55Z (298 files). Bridge: the owner passed queue history. The lead checked retained artifacts offline against the eight source-derived names: the old six-asset output was rejected for missing `editor.js` and `panel.js`, the fresh eight passed, and the R10 manifest and receipt agree. Six of the eight assets are runtime bytes; two are build provenance | Offline reuse of historical evidence; no binary was run, and this does not show that the method caused the recovery. Still open: the OPD native workflow and app-origin binding, and the AIOS native colours and opening. The missing Bridge toast is not a proven defect; no custom Undo is authorized. In one fresh-context rehearsal of five incident packets, every decision kept these limits: the incomplete package, the installed but unaccepted workflow and visual checks, the toast without an established contract, and the dropped accepted centre amendment. This tested decisions only, with no live product action and no claim of general reliability. Independent review of the exact candidate and its checks is recorded in the delivery PR |

foundation/factory-foundation/SKILL.md

@@ -3,8 +3,8 @@ name: factory-foundation
 description: Prepare or assess a software project's engineering foundation and its execution host, including reproducible setup, real checks, documentation, CI/delivery, native harness access and GitHub work tracking.
 license: MIT
 metadata:
-  version: "0.1.20"
-  updated: "2026-10-22"
+  version: "0.1.22"
+  updated: "2026-10-23"
 ---
 
 # Factory Foundation
@@ -94,7 +94,11 @@ Prepare only the chosen capabilities:
 - Establish the selected native update channel, updater ownership and maintenance
   boundary. Update checks are not automatic installs; interrupted turns, OS prompts
   and encrypted-disk unlock need an explicit recovery route. Preserve skill-local
-  changes when adopting a new reviewed version.
+  changes when adopting a new reviewed version. Prefer the official stable T3
+  channel, through the host's own maintenance process.
+- When an optional method package the owner uses changes identity, such as The
+  Onlinesourdough Method (OSM, formerly AIOS), migrate its hosts and consumers as
+  in [migrating an optional method](references/method-migration.md).
 
 Before finishing, make one short consistency pass over the sources relevant to
 the intended work, as described in [project context](references/context.md#find-the-source-before-writing).

foundation/factory-foundation/references/adoption.md

@@ -1,6 +1,6 @@
 # Adoption record
 
-Revision: 0.1.20 · Updated: 2026-10-22
+Revision: 0.1.21 · Updated: 2026-10-23
 
 Foundation identifies the appropriate existing project/adoption record and
 establishes the relevant choices. AgentOps maintains them and scoped exceptions
@@ -95,6 +95,12 @@ Reuse the following existing choice families only where they matter:
   execution host, OS/account and workspace, distinguished from the client device.
 - Selected update channels and native installer/updater ownership; checks versus
   automatic installs, idle/interruption rules, recovery and last observed result.
+- Optional method packages the owner uses on each host, such as The Onlinesourdough
+  Method (OSM): installed generation and version, invocation names, standing calls,
+  context home and IDs, and the current recovery route, as in
+  [migrating an optional method](method-migration.md).
+- For a stronger worker boundary: the rootless-container or VM comparison, its
+  evidence and the decision, as in the [setup guide](setup.md#1-choose-the-boundary).
 - Host continuity, where chosen: the host coordinator's thread and mandate, and
   the projects whose leads it coordinates with. For each startup stage (disk
   unlock, headless service boot, network routes, desktop autostart after login,

foundation/factory-foundation/references/engineering.md

@@ -1,6 +1,6 @@
 # Engineering foundation for a software project
 
-Revision: 0.1.9 · Updated: 2026-10-10
+Revision: 0.1.21 · Updated: 2026-10-23
 
 Use when preparing or assessing a project's engineering conditions: setup, checks,
 standards, design continuity, documentation, delivery and operation. [Project
@@ -190,5 +190,5 @@ This guide and [CI and delivery](ci-delivery.md) adapt and generalize the
 `aios-project-foundation` 1.1.1 skill from
 [AIOS-plugin](https://github.com/onlinesourdough/AIOS-plugin) at commit
 `3977b4de6da004bdbca47e383862390c2e4cd1fe`, MIT License, Copyright (c) 2026 Gustav
-Anderson. The same license text accompanies this skill. Factory requires no AIOS
-installation.
+Anderson. The same license text accompanies this skill. Factory requires no
+installation of that plugin, now The Onlinesourdough Method (OSM).