From 27ce6d034144cea5a8d9e6640f7ebfd2a6ecc5e8 Mon Sep 17 00:00:00 2001 From: gustavonline <8681157+gustavonline@users.noreply.github.com> Date: Fri, 23 Oct 2026 13:36:39 +0200 Subject: [PATCH 1/4] Prepare OSM consumers and native host migration Keep Factory independent while preparing version-aware optional-method cutover and recovery. Consolidate native T3 stable and boundary guidance. Refs #93, #32, #34. Co-authored-by: Claude Opus 5.5 --- VERSION | 2 +- VISION.md | 5 +- docs/architecture.md | 13 +- docs/qualification.md | 3 +- foundation/factory-foundation/SKILL.md | 10 +- .../factory-foundation/references/adoption.md | 8 +- .../references/engineering.md | 6 +- .../references/method-migration.md | 116 ++++++++++++++++++ .../factory-foundation/references/setup.md | 46 ++++++- 9 files changed, 195 insertions(+), 14 deletions(-) create mode 100644 foundation/factory-foundation/references/method-migration.md diff --git a/VERSION b/VERSION index baa9837..7906299 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.20 +0.1.21 diff --git a/VISION.md b/VISION.md index 5e15779..13dcb03 100644 --- a/VISION.md +++ b/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 diff --git a/docs/architecture.md b/docs/architecture.md index fe22bd2..7131c58 100644 --- a/docs/architecture.md +++ b/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,17 @@ 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). + ## Sources kept by this package | Need | Canonical source | diff --git a/docs/qualification.md b/docs/qualification.md index a253cb4..deae3c3 100644 --- a/docs/qualification.md +++ b/docs/qualification.md @@ -1,6 +1,6 @@ # Qualification -Revision: 0.1.20 · Updated: 2026-10-22 +Revision: 0.1.21 · 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,7 @@ 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 | +| 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). Source candidate only | Package, unit and staging checks, behavioral evidence and independent review are pending. 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 | diff --git a/foundation/factory-foundation/SKILL.md b/foundation/factory-foundation/SKILL.md index f65c009..42e1603 100644 --- a/foundation/factory-foundation/SKILL.md +++ b/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.21" + 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). diff --git a/foundation/factory-foundation/references/adoption.md b/foundation/factory-foundation/references/adoption.md index 1e90238..e716081 100644 --- a/foundation/factory-foundation/references/adoption.md +++ b/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, diff --git a/foundation/factory-foundation/references/engineering.md b/foundation/factory-foundation/references/engineering.md index c5ad42e..878c1c5 100644 --- a/foundation/factory-foundation/references/engineering.md +++ b/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). diff --git a/foundation/factory-foundation/references/method-migration.md b/foundation/factory-foundation/references/method-migration.md new file mode 100644 index 0000000..d0d0908 --- /dev/null +++ b/foundation/factory-foundation/references/method-migration.md @@ -0,0 +1,116 @@ +# Migrate an optional method package on a host + +Revision: 0.1.21 · Updated: 2026-10-23 + +Factory depends on no personal-method package. Some owners also use one, such as +**The Onlinesourdough Method (OSM)**, formerly AIOS. When that package changes its +identity, the hosts and consumers that call it must move without breaking working +calls or the owner's context. This guide covers that host and consumer side. The +package's own repository owns its source, release and distribution. + +## OSM naming, as of 2026-10-23 + +- The public name is The Onlinesourdough Method (OSM). "Context Architecture" is a + descriptive term, not a product. The owner's instruction page, **AI Operating + Model**, keeps its name, link, selected home and IDs. +- The target plugin identity is `osm` with skills prefixed `osm-*`. The target + repository, `onlinesourdough/OSM-plugin`, is not yet current; the marketplace + publisher `online-sourdough` stays. +- The order is fixed: a qualified native package candidate + ([OSM #62](https://github.com/onlinesourdough/AIOS-plugin/issues/62)), then host + and consumer preparation ([Factory #93](https://github.com/arcitai/factory/issues/93)), + then the verified distribution and repository cutover + ([OSM #77](https://github.com/onlinesourdough/AIOS-plugin/issues/77)). The parent + ledger is [OSM #76](https://github.com/onlinesourdough/AIOS-plugin/issues/76). + +Until that candidate is qualified, the current AIOS invocation names, repository +URLs and marketplace selectors stay current and working. Do not rewrite them into +future names that do not resolve yet. + +## Classify before changing + +Sort every occurrence into one class: + +| Class | Examples | Rule | +| --- | --- | --- | +| Current branding | Display names and current descriptions in guidance | Update to the current name | +| Executable identifier | Invocation and skill names, plugin IDs, marketplace selectors, install URLs, MCP identifiers | Change only together with the qualified package and its real callers | +| Compatibility or storage | Managed markers such as `AIOS:BEGIN`, source keys, context page and database IDs | Keep, and document why | +| History | Release notes, past evidence, provenance and license attribution, original source URLs, old comments | Leave as written | + +Identify the installed **generation** from its version, provenance and source. +Never infer it from a prefix, namespace or display label: legacy OSM 0.1.x already +used `osm-*`, `OSM.md`, `OSM_FORMAT` and `OSM:BEGIN`, current AIOS uses other +names, and the new OSM reuses `osm-*`. A renamed label is not a migrated package, +and a legacy OSM block is not the new identity or something to delete. + +## Record the baseline + +Keep this per host, account and harness in the existing +[adoption record](adoption.md), privately: + +- the installed generation, version, source revision or manifest, and namespace + and invocation names; +- the manual and scheduled standing calls that invoke it, such as recurring + prompts, automations and skill chains; +- the context home and its IDs, source keys, user-authored rules and the AI + Operating Model link. Hosts can differ: one harness may route to a file home + while another routes to Notion. Preserve each one; do not silently replace it; +- the permissions and connectors it relies on; +- the current, scoped recovery route that restores today's working state. + +An unknown entry stays a named gap. A consumer you cannot reach, such as a project +outside this host's access, stays a required row marked unknown, not "not +applicable". + +## Gates before cutover + +All of these must hold for the host in question: + +1. **The exact candidate** from the package's owner: an immutable source revision, + package and manifest identity, a compatibility map from old to new identifiers, + the supported native install, upgrade and recovery route for this harness, and + the owner's qualification proof (clean install, upgrade keeping the existing + home, mixed installations, fresh-session discovery and invocation). +2. Owner authority for this host, account and scope. +3. The recorded baseline and its recovery route. +4. An agreed idle checkpoint for the affected work, and its holder. + +A missing gate is a blocked field naming its holder. Do not invent install +commands, URLs or controls to fill it. + +## Cut over one host + +1. Inventory and classify, as above. +2. Privately preserve the current program, registration and context-instruction + files in scope, with their full modes. Do not copy authentication or profile + roots. +3. Select the verified candidate and the compatibility route for this host's + generation. +4. Reach the idle checkpoint with the affected work's holders. Do not end + unrelated running work to rename it. +5. Apply only through the harness's supported native help, plugin or upgrade + controls that the candidate names. +6. Verify that the installed payload matches the candidate's manifest, the native + registration shows the new identity, and unrelated configuration is unchanged. +7. In a fresh target session, verify discovery, display, invocation and one real + use that reaches the same AI Operating Model, home and IDs. Check that the + standing calls resolve. +8. Only then retire the old active family through supported controls, leaving one + active family. + +Record one outcome per host: **changed and verified**, **already current**, +**blocked** (with the dependency and holder), **unavailable** (not migrated), or +**mixed, stopped**. Stop on an ambiguous generation, an unsupported native step, a +failed check or an uncertain effect. Never replay blindly, edit caches by hand or +change file modes to force a result. + +## Roll back + +Use the recorded baseline's immutable pin or selector and the harness's already +supported recovery route. Keep the current private state: context, homes, IDs and +user rules. Then verify in a fresh session that the old calls work again. +Rolling back deletes no context and no legacy blocks. + +Factory #93 stays open until each applicable host and consumer has its own +recorded outcome. diff --git a/foundation/factory-foundation/references/setup.md b/foundation/factory-foundation/references/setup.md index d4da455..0445688 100644 --- a/foundation/factory-foundation/references/setup.md +++ b/foundation/factory-foundation/references/setup.md @@ -1,6 +1,6 @@ # Set up the host and operator client -Revision: 0.1.20 · Updated: 2026-10-22 +Revision: 0.1.21 · Updated: 2026-10-23 This reference setup uses T3 Code on a Linux execution host, with a Mac and optionally a phone as clients. The host can be a laptop, workstation or VPS. @@ -14,6 +14,24 @@ and observed proof in the installation record. Native delegation and automation need their own qualification; installing them does not authorize their use. See [upstream installation](https://github.com/pingdotgg/t3code/blob/ec80933ac8cd02fec5c97b342462ccc9567cdb1e/docs/user/install.md). +Prefer the official stable channel as the normal baseline. Use a Nightly only for +a concrete capability reason, with its own qualification. The commands and +observations below stay at Nightly 2873, where they were qualified. For a stable +release, follow its own installation and update documentation, check its bytes, +migration path and supported client/server combination, and qualify it like any +other version. Move an existing host to it only through that host's own recovery +and maintenance process; a newer release does not bypass that process's open +gates. + +Keep three things apart: features in the installed T3, upstream work that is +released but not yet installed or proposed but unmerged, and boundaries the +installation actually enforces. A released fix is not installed, and an installed +one is not accepted until it works in this installation. For the Factory host, +[#34](https://github.com/arcitai/factory/issues/34) holds the selected stable target +and its maintenance gates, and [#32](https://github.com/arcitai/factory/issues/32) +holds the live roadmap of released and pending native functions. Read those issues +for current status rather than copying it here. + Start by identifying the existing project/adoption record. Use [the adoption guidance](adoption.md#persistent-choices-and-exceptions) to establish relevant persistent choices and separate intent, native application scope and @@ -34,6 +52,28 @@ Keep deployment/admin credentials outside implementation workers unless a task explicitly needs them. A second T3 project or provider config directory under the same OS user is not a filesystem sandbox. +When a stronger boundary is needed, compare a **rootless container** and a **VM** +against the same requirements before selecting either. A rootless container shares +the host kernel; a VM runs its own guest kernel. Neither is qualified merely by +starting it. Put the whole execution environment inside the boundary: the T3 +server and the host-side tools it runs, not just a provider executable, because a +wrapped provider leaves other effectful tools outside it. Compare: + +| Requirement | Check in each candidate | +| --- | --- | +| Identity and credentials | Only the selected workspace, identity and least-privilege credentials; no inherited owner home, personal connectors, browser profile, SSH agent, privileged or runtime socket, or unrelated project access | +| Workspaces | The author reaches its selected checkout; an independent reviewer reaches the immutable candidate with allocated scratch output; shared Git metadata does not expose unrelated repositories | +| Allowed and refused actions | Real file, symlink, process, network, socket and remote-tool operations, tested separately for Codex and Claude; harness sandboxing and account-synced connectors are separate checks | +| Native operation | Environment connection, provider login, delegation and approvals still work inside, with any callback or localhost reachability recorded and no broad host-network or credential escape | +| Recovery and cost | Disconnect, restart, recovery, cleanup and revoked grants actually verified, plus the maintenance and configuration effort | + +The reusable method requires no separate browser. If a task needs a browser, its +actual profile, session and access must fit the chosen boundary. Run such a +comparison only on disposable inputs in a separately prepared test area, with its +operator, allowed effects and recovery agreed; keep an unavailable check open. The +Factory comparison and its decision are tracked in +[#32](https://github.com/arcitai/factory/issues/32). + Use one persistent AgentOps thread in the owner's existing project when it has the right context and access. A separate lead project is optional, not a requirement. Activate the lead role in that thread; preserve the project's shared instructions. @@ -42,7 +82,8 @@ T3 environments/OS identities or VMs are appropriate when the lead, workers or projects require different filesystem/network trust. Keep the owner's personal account and the Factory execution account separate, -each with its own instructions. Do not copy a personal AIOS installation, personal +each with its own instructions. Do not copy a personal method installation, such +as The Onlinesourdough Method (OSM, formerly AIOS), a personal provider home, Notion workspace, browser profile or credentials into this setup. A separate OS account or provider home does not prove that connectors synced to the provider account are excluded. Check which tools a fresh native session actually @@ -546,6 +587,7 @@ compatibility are different actions. | Codex | Native installation/update support, or T3's detected provider update action | Inspect the actual installation; do not infer automatic installation merely from a version-check setting | | Linux/Omarchy | Distribution's maintained update command and notifications | Package changes, migrations, prompts and reboot are system administration; a check notification is not an unattended update | | Factory skills | Reviewed tag → staged diff → checks → deliberate adoption | Preserve local adaptations and verify discovery; do not auto-overwrite project instructions | +| Optional method package, such as OSM | The package owner's qualified native route, as in [migrating an optional method](method-migration.md) | Factory does not depend on it; preserve its context home, IDs and standing calls | Native update checks may stay enabled. Automatically applying updates requires a selected, supported and tested maintenance route: idle-work checks, bounded scope, From 5536ea71a1ebbda888a581ba9927712a8f215fd1 Mon Sep 17 00:00:00 2001 From: gustavonline <8681157+gustavonline@users.noreply.github.com> Date: Fri, 23 Oct 2026 14:04:34 +0200 Subject: [PATCH 2/4] docs: consolidate native host and optional method adoption Reconcile Factory93 with the owner-admitted native32/34/75/79 scope. Preserve current calls, compare boundaries before selection and bind recovery. Co-authored-by: Claude Opus 5.5 --- agent-ops/factory-agent-ops/SKILL.md | 4 +-- agent-ops/factory-agent-ops/references/t3.md | 33 ++++++++++++------ docs/architecture.md | 5 +++ docs/qualification.md | 2 +- .../references/method-migration.md | 21 ++++++++---- .../factory-foundation/references/setup.md | 34 ++++++++++++++----- 6 files changed, 71 insertions(+), 28 deletions(-) diff --git a/agent-ops/factory-agent-ops/SKILL.md b/agent-ops/factory-agent-ops/SKILL.md index aa6b173..547575c 100644 --- a/agent-ops/factory-agent-ops/SKILL.md +++ b/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 diff --git a/agent-ops/factory-agent-ops/references/t3.md b/agent-ops/factory-agent-ops/references/t3.md index 43753dc..0e8b927 100644 --- a/agent-ops/factory-agent-ops/references/t3.md +++ b/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 diff --git a/docs/architecture.md b/docs/architecture.md index 7131c58..041c237 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -99,6 +99,11 @@ 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 diff --git a/docs/qualification.md b/docs/qualification.md index deae3c3..4f58011 100644 --- a/docs/qualification.md +++ b/docs/qualification.md @@ -10,7 +10,7 @@ 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 | -| 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). Source candidate only | Package, unit and staging checks, behavioral evidence and independent review are pending. 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 | +| 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. Source candidate only | The correction has no fresh behavioral or independent review result yet; see the delivery PR for later proof. 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 | diff --git a/foundation/factory-foundation/references/method-migration.md b/foundation/factory-foundation/references/method-migration.md index d0d0908..a280603 100644 --- a/foundation/factory-foundation/references/method-migration.md +++ b/foundation/factory-foundation/references/method-migration.md @@ -73,7 +73,8 @@ All of these must hold for the host in question: the owner's qualification proof (clean install, upgrade keeping the existing home, mixed installations, fresh-session discovery and invocation). 2. Owner authority for this host, account and scope. -3. The recorded baseline and its recovery route. +3. The recorded baseline and its recovery route, freshly verified on the same host + before any effect (step 2 below). 4. An agreed idle checkpoint for the affected work, and its holder. A missing gate is a blocked field naming its holder. Do not invent install @@ -83,8 +84,10 @@ commands, URLs or controls to fill it. 1. Inventory and classify, as above. 2. Privately preserve the current program, registration and context-instruction - files in scope, with their full modes. Do not copy authentication or profile - roots. + files in scope on the same host, with their full modes. Then check the copy + against the current files: the same file set, bytes, sizes and full modes, and + internal links where they matter. Record what was preserved and the current + state it came from. Do not copy authentication or profile roots. 3. Select the verified candidate and the compatibility route for this host's generation. 4. Reach the idle checkpoint with the affected work's holders. Do not end @@ -107,10 +110,14 @@ change file modes to force a result. ## Roll back -Use the recorded baseline's immutable pin or selector and the harness's already -supported recovery route. Keep the current private state: context, homes, IDs and -user rules. Then verify in a fresh session that the old calls work again. -Rolling back deletes no context and no legacy blocks. +Bind rollback to both the baseline's recorded immutable source or package +identity and the harness's supported native selector or route for exactly that +identity. A reused selector alone can resolve to something else. Keep the current +private state: context, homes, IDs and user rules. If an effect was partial or +uncertain, stop and reconcile the actual state before any rollback or retry. Then +verify in a fresh session that the old calls work again. Rolling back deletes no +context and no legacy blocks, and uses no invented command, cache edit, mode +change or grant. Factory #93 stays open until each applicable host and consumer has its own recorded outcome. diff --git a/foundation/factory-foundation/references/setup.md b/foundation/factory-foundation/references/setup.md index 0445688..c8dbb38 100644 --- a/foundation/factory-foundation/references/setup.md +++ b/foundation/factory-foundation/references/setup.md @@ -21,7 +21,12 @@ release, follow its own installation and update documentation, check its bytes, migration path and supported client/server combination, and qualify it like any other version. Move an existing host to it only through that host's own recovery and maintenance process; a newer release does not bypass that process's open -gates. +gates. A cutover is verified only when the intended server and every client read +back both the exact version and the stable channel; a desktop update or a request +for one version is not that readback. A combined update action can update +providers, servers and connected machines together, so it is not a scoped version +check. Documentation of a newer launcher's rollback does not show that an older +installation has that launcher or its guarantees. Keep three things apart: features in the installed T3, upstream work that is released but not yet installed or proposed but unmerged, and boundaries the @@ -30,7 +35,17 @@ one is not accepted until it works in this installation. For the Factory host, [#34](https://github.com/arcitai/factory/issues/34) holds the selected stable target and its maintenance gates, and [#32](https://github.com/arcitai/factory/issues/32) holds the live roadmap of released and pending native functions. Read those issues -for current status rather than copying it here. +for current status rather than copying it here. Factory adds no runtime, approval +service or bridge for a function still pending upstream; it waits for the official +release and qualifies it. + +Stable T3 source documents an outside-agent route over MCP with OAuth, which an +owner-side caller could use to read, start, message and stop threads within a +chosen writable mode. That mode covers all of the environment's projects. It is +not a per-project access list, it grants no authority to decide another worker's +approval, and it is no isolation boundary. Treat it as documented source only +until it is connected and qualified in the installation; a qualified native route +like this is preferable to a custom bridge. Start by identifying the existing project/adoption record. Use [the adoption guidance](adoption.md#persistent-choices-and-exceptions) to establish @@ -43,9 +58,10 @@ Hand ongoing upkeep for the current project to AgentOps within its mandate. ## 1. Choose the boundary Use an ordinary execution account on the host, with access to the selected repos -and tools. On a shared personal machine, prefer a dedicated VM with its own -unprivileged guest account. Keep the personal home, SSH agent, browser, clipboard -and host sockets outside it; admit shared folders/devices only for a stated need. +and tools. On a shared personal machine, give the agents a separate boundary with +its own unprivileged account: a VM or a rootless container, selected only after the +comparison below. Keep the personal home, SSH agent, browser, clipboard and host +sockets outside it; admit shared folders/devices only for a stated need. On a dedicated host, a separate unprivileged OS user may be sufficient for the selected workload. It shares the kernel and is not equivalent to a VM. Keep deployment/admin credentials outside implementation workers unless a task @@ -72,13 +88,15 @@ actual profile, session and access must fit the chosen boundary. Run such a comparison only on disposable inputs in a separately prepared test area, with its operator, allowed effects and recovery agreed; keep an unavailable check open. The Factory comparison and its decision are tracked in -[#32](https://github.com/arcitai/factory/issues/32). +[#32](https://github.com/arcitai/factory/issues/32). A Cloudflare-based approach +remains optional research in [#79](https://github.com/arcitai/factory/issues/79), +not a third required boundary. Use one persistent AgentOps thread in the owner's existing project when it has the right context and access. A separate lead project is optional, not a requirement. Activate the lead role in that thread; preserve the project's shared instructions. Workers receive the target project's context and skills. Separate provider profiles, -T3 environments/OS identities or VMs are appropriate when +T3 environments/OS identities, VMs or containers are appropriate when the lead, workers or projects require different filesystem/network trust. Keep the owner's personal account and the Factory execution account separate, @@ -582,7 +600,7 @@ compatibility are different actions. | Component | Native route | Boundary | | --- | --- | --- | | Desktop/mobile clients | Official application updater or store/beta channel | Match the host's protocol; an updated client does not update the server | -| T3 background server | The named environment's Update server action or `t3 update ` | Reconcile active turns and background commands first; it restarts the service | +| T3 background server | The named environment's Update server action or `t3 update ` | Reconcile active turns and background commands first; it restarts the service. Read back both version and channel; a service keeps its current channel | | Claude native installation | Native background updates; `claude doctor` reports installation, channel and updater state | New version takes effect on the next process; custom/copied launchers may prevent adoption | | Codex | Native installation/update support, or T3's detected provider update action | Inspect the actual installation; do not infer automatic installation merely from a version-check setting | | Linux/Omarchy | Distribution's maintained update command and notifications | Package changes, migrations, prompts and reboot are system administration; a check notification is not an unattended update | From baf569213e5f2a0d1ff84b8d4797fdf1eec2cf85 Mon Sep 17 00:00:00 2001 From: gustavonline <8681157+gustavonline@users.noreply.github.com> Date: Fri, 23 Oct 2026 14:29:39 +0200 Subject: [PATCH 3/4] docs: verify current recovery after the idle checkpoint Resolve independent R78-1 without changing any host or native control. Preserve preliminary copies and require consistency immediately before effects. Co-authored-by: Claude Opus 5.5 --- docs/qualification.md | 2 +- .../references/method-migration.md | 49 +++++++++++++------ 2 files changed, 35 insertions(+), 16 deletions(-) diff --git a/docs/qualification.md b/docs/qualification.md index 4f58011..6833c96 100644 --- a/docs/qualification.md +++ b/docs/qualification.md @@ -10,7 +10,7 @@ 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 | -| 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. Source candidate only | The correction has no fresh behavioral or independent review result yet; see the delivery PR for later proof. 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 | +| 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 | That recovery correction has no review result yet; see the delivery PR for the exact later review. 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 | diff --git a/foundation/factory-foundation/references/method-migration.md b/foundation/factory-foundation/references/method-migration.md index a280603..5cd5f55 100644 --- a/foundation/factory-foundation/references/method-migration.md +++ b/foundation/factory-foundation/references/method-migration.md @@ -73,9 +73,11 @@ All of these must hold for the host in question: the owner's qualification proof (clean install, upgrade keeping the existing home, mixed installations, fresh-session discovery and invocation). 2. Owner authority for this host, account and scope. -3. The recorded baseline and its recovery route, freshly verified on the same host - before any effect (step 2 below). -4. An agreed idle checkpoint for the affected work, and its holder. +3. An agreed idle checkpoint for the affected work, and its holder. +4. A consistent **current** recovery copy on the same host, made or refreshed at + that checkpoint and verified immediately before any effect (step 5 below), with + the recorded immutable baseline identity and its supported native recovery + route. A copy taken earlier does not satisfy this gate by itself. A missing gate is a blocked field naming its holder. Do not invent install commands, URLs or controls to fill it. @@ -83,29 +85,46 @@ commands, URLs or controls to fill it. ## Cut over one host 1. Inventory and classify, as above. -2. Privately preserve the current program, registration and context-instruction - files in scope on the same host, with their full modes. Then check the copy - against the current files: the same file set, bytes, sizes and full modes, and - internal links where they matter. Record what was preserved and the current - state it came from. Do not copy authentication or profile roots. +2. If useful, privately take a preliminary copy of the program, registration and + context-instruction files in scope, with their full modes. It is only + preliminary: affected work may still change those files, so it does not + satisfy the recovery gate. 3. Select the verified candidate and the compatibility route for this host's generation. -4. Reach the idle checkpoint with the affected work's holders. Do not end - unrelated running work to rename it. -5. Apply only through the harness's supported native help, plugin or upgrade +4. Reach the idle checkpoint with the affected work's holders. Quiesce only the + affected work; healthy independent work continues, and unrelated running work + is not ended to rename it. +5. **At that checkpoint, before any native effect,** establish the current + recovery copy: + - Confirm every relevant holder is accounted for and the scoped sources stay + quiet. + - Make or refresh the copy on the same host, with full modes. Check that the + source is stable before the copy and after it, and that the copy matches the + current files: the same file set, bytes, sizes and full modes, and internal + links where they matter. A preliminary copy counts only after this fresh + comparison. If anything changed, refresh and reconcile it, keeping existing + recovery material. + - Keep the recorded immutable baseline identity bound to its supported native + recovery route, and preserve the current home, IDs, user rules and + permissions. Do not copy authentication or profile roots. + - Stop before applying on an unknown holder, a failed consistency check, new + editing or an uncertain effect. Use no manual cache, mode or grant edits and + no custom fence. +6. Apply only through the harness's supported native help, plugin or upgrade controls that the candidate names. -6. Verify that the installed payload matches the candidate's manifest, the native +7. Verify that the installed payload matches the candidate's manifest, the native registration shows the new identity, and unrelated configuration is unchanged. -7. In a fresh target session, verify discovery, display, invocation and one real +8. In a fresh target session, verify discovery, display, invocation and one real use that reaches the same AI Operating Model, home and IDs. Check that the standing calls resolve. -8. Only then retire the old active family through supported controls, leaving one +9. Only then retire the old active family through supported controls, leaving one active family. Record one outcome per host: **changed and verified**, **already current**, **blocked** (with the dependency and holder), **unavailable** (not migrated), or **mixed, stopped**. Stop on an ambiguous generation, an unsupported native step, a -failed check or an uncertain effect. Never replay blindly, edit caches by hand or +failed check or an uncertain effect. After a partial effect, reconcile the actual +state before any retry or rollback. Never replay blindly, edit caches by hand or change file modes to force a result. ## Roll back From 2a687e5d30a44d9264e8f38b35f6607a09e512b6 Mon Sep 17 00:00:00 2001 From: gustavonline <8681157+gustavonline@users.noreply.github.com> Date: Fri, 23 Oct 2026 17:40:56 +0200 Subject: [PATCH 4/4] docs: reconcile canonical OSM prerelease adoption provenance Record the tagged prerelease separately from per-host adoption and preserve the supported disable, acceptance and recovery sequence. Co-authored-by: Claude Opus 5.5 --- VERSION | 2 +- docs/qualification.md | 5 +- foundation/factory-foundation/SKILL.md | 2 +- .../references/method-migration.md | 74 +++++++++++++------ 4 files changed, 58 insertions(+), 25 deletions(-) diff --git a/VERSION b/VERSION index 7906299..7e72641 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.21 +0.1.22 diff --git a/docs/qualification.md b/docs/qualification.md index 6833c96..6f33b04 100644 --- a/docs/qualification.md +++ b/docs/qualification.md @@ -1,6 +1,6 @@ # Qualification -Revision: 0.1.21 · Updated: 2026-10-23 +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,7 +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 | -| 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 | That recovery correction has no review result yet; see the delivery PR for the exact later review. 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 | +| 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 | diff --git a/foundation/factory-foundation/SKILL.md b/foundation/factory-foundation/SKILL.md index 42e1603..6293da2 100644 --- a/foundation/factory-foundation/SKILL.md +++ b/foundation/factory-foundation/SKILL.md @@ -3,7 +3,7 @@ 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.21" + version: "0.1.22" updated: "2026-10-23" --- diff --git a/foundation/factory-foundation/references/method-migration.md b/foundation/factory-foundation/references/method-migration.md index 5cd5f55..e06aca7 100644 --- a/foundation/factory-foundation/references/method-migration.md +++ b/foundation/factory-foundation/references/method-migration.md @@ -1,6 +1,6 @@ # Migrate an optional method package on a host -Revision: 0.1.21 · Updated: 2026-10-23 +Revision: 0.1.22 · Updated: 2026-10-23 Factory depends on no personal-method package. Some owners also use one, such as **The Onlinesourdough Method (OSM)**, formerly AIOS. When that package changes its @@ -8,24 +8,44 @@ identity, the hosts and consumers that call it must move without breaking workin calls or the owner's context. This guide covers that host and consumer side. The package's own repository owns its source, release and distribution. -## OSM naming, as of 2026-10-23 +## OSM status, as of 2026-10-23 - The public name is The Onlinesourdough Method (OSM). "Context Architecture" is a descriptive term, not a product. The owner's instruction page, **AI Operating Model**, keeps its name, link, selected home and IDs. -- The target plugin identity is `osm` with skills prefixed `osm-*`. The target - repository, `onlinesourdough/OSM-plugin`, is not yet current; the marketplace - publisher `online-sourdough` stays. -- The order is fixed: a qualified native package candidate - ([OSM #62](https://github.com/onlinesourdough/AIOS-plugin/issues/62)), then host - and consumer preparation ([Factory #93](https://github.com/arcitai/factory/issues/93)), - then the verified distribution and repository cutover - ([OSM #77](https://github.com/onlinesourdough/AIOS-plugin/issues/77)). The parent - ledger is [OSM #76](https://github.com/onlinesourdough/AIOS-plugin/issues/76). - -Until that candidate is qualified, the current AIOS invocation names, repository -URLs and marketplace selectors stay current and working. Do not rewrite them into -future names that do not resolve yet. +- The canonical repository is + [onlinesourdough/OSM-plugin](https://github.com/onlinesourdough/OSM-plugin). Its + plugin is `osm`, selected as `osm@online-sourdough` in Codex and Claude; the + marketplace publisher `online-sourdough` is unchanged. The core skills are + `osm` and `osm-*`, while `content` and `diffusion-studio` keep their unprefixed + names. +- Public metadata read on 2026-10-23: + [v0.30.0](https://github.com/onlinesourdough/OSM-plugin/releases/tag/v0.30.0) is a + **prerelease**, not a stable release. Its tag is the merge commit + `314dcf17a06014df472a32cdb10f847672cba0be` of + [PR #80](https://github.com/onlinesourdough/OSM-plugin/pull/80). Package CI + passed on that pull request's head commit, not on the tag commit itself. +- The package lane ([OSM #62](https://github.com/onlinesourdough/OSM-plugin/issues/62)), + the distribution lane ([OSM #77](https://github.com/onlinesourdough/OSM-plugin/issues/77)) + and the parent ledger ([OSM #76](https://github.com/onlinesourdough/OSM-plugin/issues/76)) + remain with their own owners. Host and consumer preparation is + [Factory #93](https://github.com/arcitai/factory/issues/93). + +Publication is not use. A release migrates no host, and the metadata above shows +no host or caller using it. On each host, keep the working AIOS 0.29 callers, +selectors and existing reviewed installation until that host has its own exact +compatible candidate, owner authority, idle checkpoint with a current quiet +recovery copy, fresh-session discovery, invocation and use, and a qualified +rollback. Do not silently replace an installed reviewed preview, such as a Setup +preview, with the base release; a separately versioned preview needs its own +qualification and selection. + +Take harness-specific steps from the candidate's own pinned +[native installation](https://github.com/onlinesourdough/OSM-plugin/blob/314dcf17a06014df472a32cdb10f847672cba0be/docs/native-installation.md) +and [migration](https://github.com/onlinesourdough/OSM-plugin/blob/314dcf17a06014df472a32cdb10f847672cba0be/skills/osm-setup/references/migration.md) +documents; this guide does not repeat their commands. A fixed-version install names +an existing reviewed, immutable ref. The unpinned route in the README follows the +`main` branch, so it is not a qualified fixed version. ## Classify before changing @@ -111,14 +131,23 @@ commands, URLs or controls to fill it. editing or an uncertain effect. Use no manual cache, mode or grant edits and no custom fence. 6. Apply only through the harness's supported native help, plugin or upgrade - controls that the candidate names. + controls that the candidate names. When the new identity is a new selector, + as `osm` is for `aios`, this installs it; it is not an in-place update of the + old one. Record the old source's exact ref and scope first. 7. Verify that the installed payload matches the candidate's manifest, the native registration shows the new identity, and unrelated configuration is unchanged. -8. In a fresh target session, verify discovery, display, invocation and one real +8. Before acceptance, disable the old active source through the candidate's + qualified native control, so no session sees two effective sources. Where the + candidate documents a version-checked control for exactly that one + registration, use only that control; never edit configuration wholesale or by + hand. If no supported disable exists, use only the candidate's supported + removal and recovery route at the idle checkpoint. +9. In a fresh target session, verify discovery, display, invocation and one real use that reaches the same AI Operating Model, home and IDs. Check that the standing calls resolve. -9. Only then retire the old active family through supported controls, leaving one - active family. +10. Only after that acceptance, and once no session or profile depends on it, + retire the disabled old registration through supported controls, leaving one + active family. Record one outcome per host: **changed and verified**, **already current**, **blocked** (with the dependency and holder), **unavailable** (not migrated), or @@ -133,8 +162,11 @@ Bind rollback to both the baseline's recorded immutable source or package identity and the harness's supported native selector or route for exactly that identity. A reused selector alone can resolve to something else. Keep the current private state: context, homes, IDs and user rules. If an effect was partial or -uncertain, stop and reconcile the actual state before any rollback or retry. Then -verify in a fresh session that the old calls work again. Rolling back deletes no +uncertain, stop and reconcile the actual state before any rollback or retry. If +fresh-session acceptance fails, disable the new source and re-enable the old one, +or reinstall the exact old source through its native route; never delete or change +data homes or authentication. Then verify in a fresh session that the old calls +work again. Rolling back deletes no context and no legacy blocks, and uses no invented command, cache edit, mode change or grant.