Repository navigation
Qualify safe native T3 maintenance and stable-channel adoption #34
Description
Current checkpoint — 29 October 2026, 23:25 UTC
Lab Ops is now active on official Stable0.1.5; qualification is still in progress. Only its foreground executable path changed. The three prepared baseline environments remain3796. Shared3010, the existing Mac Nightly3010 client, provider CLIs, OS and other projects were untouched.
The official artifact/hash and actual DB preflight passed. At an idle boundary, the operator retained a verified private cold copy, moved native userdata aside intact and restored it from that archive. Every selected restored file matched; SQLite integrity, native history/identity and reconnection in the SAME Mac GUI passed. Scoped read postflight also passed: selected Factory Notion/repository accessible, known private Data & Context refused. This is actual same-host native userdata restore, not a full VM/provider-profile restore or completed updater rollback. Useful model continuation after this restore remains pending.
Actual stop limits are retained. A normal service-stop request returned, but the foreground Sandbox CLI timed out/exit125; the VM stop succeeded. A later verified idle guest-first TERM produced foreground exit130 and one automatic return through the existing native failure-restart policy. No duplicate start or exit-code masking. These observations do not qualify clean manual shutdown, a native T3 managed launcher, whole-host boot or unattended updates. The private receipts retain both failed and successful stages.
Stable0.1.5 already ran real model work on three fresh task workers through the earlier3796 lead, including repair/two-review acceptance, same-thread recovery and verified archive/cleanup (R7 evidence). The next affected check is useful model/review/delivery behavior from the restored stable Ops. Its final configuration delta is with two existing independent Opus5.5 High reviewers; their first attempts failed on a confirmed provider limit, without verdict. The refreshed exact input waits for that reset. No blanket intake or automatic updater is enabled.
The earlier Nightly/version receipt and Docker login recovery remain dated evidence. Reliable unattended login renewal is not established. Keep shared-host/client/OS state-holder and recovery holds below; no forced combined update. #34 remains open.
Historical shared-host maintenance record — 23 October 2026
Factory needs an owned opportunity for safe official T3 maintenance and a verified return to work. Prefer the official stable channel for the normal baseline; a nightly needs a concrete capability reason and separate qualification. Already current should mean a recorded no-op.
Selected target — 23 October 2026: stable v0.1.2, published 22 October, commit 044f07257c9684ae4543bd1e1ebf9c394e9e3830. The running server still reports 3010. This stable contains PR #20037 and the question/wait/UI fixes listed in #32, but not the open Home/approval-notice/remote-delegation proposals. It is a target, not an installed or accepted update. This supersedes the old 3190 target and the staged 3457 candidate in the dated comments; their artifact proof does not qualify this different release. Keep the accepted R10 safety/recovery requirements and refresh the affected official-artifact, migration and compatibility evidence before any update.
Channel and transaction scope: the v0.1.2 update guide says the combined update action updates providers, servers and connected machines, while a background service stays on its current release channel. Inspect the actual installation's supported controls and verify both version and stable-channel selection on the intended server and clients; a desktop update or exact-version request alone is not readback of the whole cutover. Do not use the combined action as a scoped version check. The new launcher rollback contract does not prove the old 3010 installation already has that launcher or its guarantees.
Official release metadata identifies Linux x64 server archive t3-0.1.2-linux-x64.tar.gz (94,476,949 bytes; SHA256 7aed625cb961938df174c1a067c0f05235360940b53e882a1643126b754da16c) and desktop T3-Code-0.1.2-x86_64.AppImage (164,553,071 bytes; SHA256 cf01e2d167eff9d01c4c1004d31b2c0da9e2522cc94262e41644d1cb15dfdb5c). This is official metadata, not a local download, executable check or adoption receipt. Select the artifact that actually owns the installation and verify its downloaded bytes in the existing operator's safe procedure.
16 October remains deferred. The earlier copy was invalid because a desktop SSH route launched a server after service stop. It must never be restored. No update was attempted. The original official 3010 service recovered and completed a real Factory provider postflight; PR #20037's watch and notification gap were restored/reconciled.
The latest pre-hold check stopped before any new hold, stop or copy. Two gaps remain:
- State-holder coverage: some native OS processes cannot be fully inspected with current rights. Their names do not prove that they hold no application state; unreadability also does not prove that they are writers.
- Launcher coverage: the Mac uses T3 Connect with an SSH fallback. The auth CLI reports every session disconnected even while the UI is connected, so it cannot prove client absence or quiet launchers. The current Access UI route provides no usable live-client inventory. One client's switch does not fence another client.
There is no qualified stop/copy action yet. R5's accepted pre-stop gate stays unchanged. Resume only when existing authorized native evidence accounts for relevant state holders and every relevant owning client can keep its autolaunch route quiet during a fresh safe job window. Missing coverage defers maintenance; it does not justify broader rights, token revocation, forced job interruption or a custom guard.
Once that floor is met, the next reviewed operation is backup-only: verify a fresh private consistent copy, start unchanged 3010, independently reconnect and prove one continuation, then restore saved connections/producers. An actual update needs a fresh then-current recovery copy and separate acceptance. The selected official stable candidate above must be checked on its own bytes, migration path and supported client/server combination before installation. Do not overwrite or relabel the retained 3190/3457 evidence as proof for it.
The existing host operator owns protected recovery/postflight; Factory owns follow-through. No new owner decision is requested for these technical gaps. Existing follow-up remains owned; #32 now records PR #20037 as merged and present in stable, with local adoption still pending. The daily heartbeat is follow-up, not an installed timer. Detailed evidence is private on Z13. No parked patch, parallel maintenance or new runtime.
Activity
gustavonline commentedon Oct 15, 2026
Mac-opdateringsdialogen tilbyder 3158 til selve Mac-appen og nævner kun en Claude-opdatering på det tilsluttede environment. Den viser ikke Z13-serverens mål. Dialogen blev annulleret uden ændringer; en frisk native readback viser fortsat server 3010.
#34 er derfor stadig udsat. Samme forløb fortsætter først med en verificeret servermålversion eller et reelt allerede-ajour-resultat, en sikker global jobgrænse, privat recovery og navngivet ansvar for service/reconnect samt én faktisk genoptagelse. Den viste indstilling om at fortsætte threads er slået til; genoptagelsen er endnu ikke prøvet.
Det præcise host-handoff er gemt i det eksisterende private kvalifikationsmateriale. De tilgængelige AgentOps-værktøjer kan ikke læse serverens opdateringsmål, og
updatemå ikke bruges som forespørgsel. Den eksisterende daglige opfølgning genbruges; ingen parallel vedligeholdelseskørsel, pollingløkke, genstart eller timer er startet. Specialpatches forbliver parkeret.gustavonline commentedon Oct 16, 2026
The new docs identify a real official improvement to assess at a future safe boundary. Nightly3218 is published on GitHub and npm. Its tagged server-ownership lock is absent from3010 source. It prevents concurrent server ownership, but releases on exit: it is not an admission/drain barrier or a fence covering the stopped copy window and every other state writer.
Correction to any “program rollback only” shorthand: 3010's launcher source already contains SQLite main/WAL/SHM snapshot/restore. That does not verify the currently running2967 launcher's exact guarantees, attachments/other files, or our failed full recovery copy. The invalid copy remains unusable.
Current update/recovery docs describe channel-aware native updates and durable continuation, with exclusions for waiting approvals/questions/secrets and unsupported resume state. They do not promise zero interruption or complete job/effect recovery.
**No new host action:**3010 remains installed; no hold, stop, copy or update was attempted. Today's deferred result and accepted pre-stop gate remain. Resume only with a supported, qualified launcher/holder-safe route, private recovery and independent reconnect plus a real continuation. No Mac request or parallel maintenance job is created by this research.
gustavonline commentedon Oct 19, 2026
Coordinator migration readiness — 19 October
Preparation only: no migration, update, reboot or new maintenance run. The owner desktop and Factory service use separate OS accounts; owner context must stay out of Factory.
Git preparation is now complete, according to the existing coordinator: both private continuity checkouts share the same clean commit, with 11 tracked files and six verified snapshots. This supersedes only the earlier non-Git finding. Native saved-project pairing and association of this existing chat remain missing, so same-chat handoff is still unready. App computer use was denied and not bypassed; no native project-creation tool is exposed there. The next prerequisite remains supported native app/UI association, with no new trial, actor or duplicate coordinator.
The Z13 desktop is installed, but user-service linger does not prove the Codex app starts after login or can schedule work without the Mac. Native scheduling needs the computer and app running. Before retiring the Mac fallback, verify supported access to existing T3 leads and one exactly-once wake in the same coordinator chat with the Mac disconnected. CLI presence alone proves neither.
Maintenance stays deferred at the existing holder/autolaunch gate. The visible Omarchy notification is not an update plan: cached package metadata is stale, and the native updater can continue after snapshot failure and later restart components. A later window needs a concrete transaction, verified private recovery coverage and an independent unlock/login/postflight owner. Keep OS update, T3 update and chat migration separate.
Factory owns the saved readiness plan; the existing host operator owns protected recovery. Healthy jobs and the current PR20037 watch remain untouched. No new owner decision is needed for this preparation.
gustavonline commentedon Oct 20, 2026
Official Nightly 3457 is verified and staged; Factory is still running 3010. No hold, stop, backup or update has begun.
The owner has requested a usable update window today. OPD and Bridge have reached terminal checkpoints, AIOS's accepted source is frozen, and the host's 258 top-level native PR-watch lists are all off. This is preparation, not an admission lock.
The concrete route is: qualify one consistent private backup and return to unchanged 3010, then take a fresh recovery copy before the exact official 3457 update. The old local updater also rewrites the next-start service when restart is declined, so it is not being used as a version query or staging command.
Three precise conditions remain before service stop:
The procedure includes the release's migration limits: keep both databases and shared data; migrated text is not a live provider checkpoint; a binary downgrade is not data recovery. New launcher rollback documentation does not prove the old installation has run that path.
Independent Sol Max review accepts the corrected R10 procedure with explicit live gates. Backup-only qualification and the actual update remain NOT RUN. The next capable-holder action is one read-only pre-stop receipt from an existing independent Factory-account terminal, resolving the controls and relevant-holder evidence above; no new owner product decision is needed. No repeated package proof, generic owner readiness certification, broader access, custom guard, or invalid old recovery is requested. #83 retains the startup and backup-visibility evidence. Product tests can use their explicitly installed current stages; this is not whole-product acceptance.
[-]Qualify one daily native T3 update pause and reliable resumption[/-][+]Qualify safe native T3 maintenance and stable-channel adoption[/+]gustavonline commentedon Oct 24, 2026
Owner follow-up,24 October: the selected target remains official stable v0.1.2. Git ancestry freshly confirms that its044f072 source descends from the currently recorded3010/d83929ad baseline (1958 commits ahead, none behind). This establishes source lineage, not functional acceptance.
The owner authorizes the cutover when jobs and clients are actually stopped or safely paused. A fresh native census still shows three OSM independent reviews, the existing OpenPaperDesign repair writer and Factory research, so the all-idle condition is not met. The Mac-linked execution runtime was independently observed still on3010. No update or service stop has occurred.
The same Foundation/operator handoff now owns the concrete remaining R10 pre-stop recovery-control, holder and all-client/autolaunch evidence, then backup-only/unchanged-version recovery proof before the exact stable transaction and real continuation. No further generic procedure review is needed. Stable channel selection must be verified separately from installing the version; current work and every existing recovery gate remain preserved.
gustavonline commentedon Oct 24, 2026
The owner's 24 October mandate to move to official stable is recorded. No stop/update is eligible yet: the supplied current native census still has three OSM reviewers and OPD's existing writer active. Their leads keep ownership; nothing was paused or interrupted here. The #91 architecture recommendation is now published/read back, separately from this host transaction.
Actual new Factory-account preparation:
t3code.service. A server-unit stop alone is not evidence that all native work/state holders are quiet. Existing inaccessible-holder evidence remains unknown; no denied fd/maps or alternative reader was used.7aed625cb961938df174c1a067c0f05235360940b53e882a1643126b754da16c; AppImage164,553,071B /cf01e2d167eff9d01c4c1004d31b2c0da9e2522cc94262e41644d1cb15dfdb5c. This is byte staging, not installation or recovery of current data.--channel stableand--base-dirfor its per-machine update. No update action or combined UI updater was run. The old launcher's rollback guarantees are not inferred from new-release documentation.Next concrete holder/action: the existing host recovery operator supplies one read-only receipt from its already-authorized normal Factory-account terminal/SSH outside T3: actual route/principal, this same user manager/service, and control retained independently of T3. Then reconcile accountable state holders and each owning client's actual normal connection/autolaunch quieting controls at the fresh job boundary. This includes Z13 desktop and Mac/T3 Connect/SSH fallback routes; the companion's other-app lock remains intact. One client's switch, an inactive route or the known misleading auth-session census cannot substitute.
Keep accepted R10 unchanged: after those gates, backup-only consistent recovery → unchanged3010 reconnect/useful continuation → a fresh recovery copy before the separate stable server/desktop/client cutover. Verify actual version and stable channel, same conversations/settings and useful continuation on each affected installation. LiveV2 migrations62–67, post-copy divergence and current owner state remain protected. Encrypted reboot/unlock stays separate. No stop, live copy, restart, provider update, grant or permission effect occurred. Bounded isolation preparation continues under #32 without launching a runtime.
gustavonline commentedon Oct 27, 2026
A new separate Factory Lab OS account and loopback T3 stable0.1.2 instance have been prepared for the owner's bounded Lab task. This is a fresh installation, not a migration or update of the existing shared nightly3010 server, its data, desktop clients or other projects.
The old shared service and OPD/OSM jobs were not stopped, updated or rebooted. Every existing recovery, state-holder, idle-window and client/autolaunch gate in this issue remains. No old backup was restored and no full stable adoption is claimed. Source/connection work and the still-held native worker pilot are recorded in #32 and PR100; private installation evidence remains private.
gustavonline commentedon Oct 27, 2026
The new dedicated Lab now runs native T3 0.1.2 inside its own Z13 sandbox, under a reviewed native user service. PR #102 and v0.1.25 record the bounded pilot and recovery limits; see #32 for the access/worker result.
After retaining and repairing an initial service failure, two idle crash/restart cycles remained stable, history was preserved without automatic replay, and normal stop completed within the configured limit. The service is deliberately not enabled at boot. The obsolete dedicated host-only preflight was stopped and disabled at a confirmed idle checkpoint, preserving its state.
This is not the shared-host stable-channel cutover. The shared Nightly instance, other projects, their jobs and existing holds remain unchanged. Host reboot/unlock, safe updates, active-write interruption, network/power recovery, automatic cross-environment handoff and the client/maintenance acceptance work in this issue remain open. No native update schedule or custom coordinator was added.
gustavonline commentedon Oct 28, 2026
28 October: separate Lab qualification; shared-host hold remains
The dedicated Factory Lab moved to official 0.1.4-nightly.20261027.3796 because the required native linked-environment delegation is absent from stable 0.1.3. The exact official archive was checksum-verified; the complete cold premigration native state was restored into scratch and checked before migration 67→72. The existing Mac app can operate the new Lab in the same GUI. PR #103 / v0.1.26 records this dated scope.
The direct native binary fixed the old npm launcher's normal-stop status problem. Two idle crash/restart cycles each recovered the expected environment and stayed stable; boot remains disabled. This does not qualify active-write interruption, power loss, full native restore/resume, automatic updates or unattended intake. The update offer now visible in the app is not automatically accepted by this evidence.
The old shared service was read back separately today: still active on its original process started 20 October. Other projects/jobs, client launchers and the accepted state-holder/launcher holds were not bypassed or interrupted. Its safe maintenance transaction remains unqualified. A dedicated Lab update does not qualify that separate shared installation, its OS update or a reboot.
The 23 October stable target and artifact details in this issue body are historical selection evidence, not a current claim that it was adopted or is the newest release. Preserve the accepted R5/R10 gates and choose/check the then-current supported candidate when a safe window is actually available. Do not use a combined multi-machine/provider update as a scoped check.
Current record and recovery paths are private in the existing installation record. No new scheduler, approval pump, host privilege bridge or automatic maintenance policy was enabled. #32 retains per-agent sandbox lifecycle and approval/worktree gaps; vendor/backend reuse and maintainability are being assessed there.
gustavonline commentedon Oct 28, 2026
28 October: installed Lab baseline and next GUI qualification candidate
Read-only observations at 18:08 UTC on 28 October identify 0.1.4-nightly.20261027.3796 and migration 72 in each of the four isolated Factory Lab environments. Their T3 binary hashes match the selected payload and the temporary linked VM's retained preflight hash. This Lab readback does not qualify the original shared Z13 service or the Mac client for an update.
The operator's check of official release/PR pages on 28 October at 18:05 UTC found that GitHub's latest-stable route resolved to v0.1.3, released 27 October. This is a web-source observation, not a downloaded artifact. The earlier v0.1.2 target in this issue is historical, not the current installed Lab version or latest stable at that check.
Nightly 0.1.4-nightly.20261028.3824, released 28 October, includes upstream PR #26434: remote-delegate icons, a parent row and linked Settings refresh. It is a relevant source/release candidate, not a downloaded, installed or accepted replacement. It does not establish VM-creation authority for AgentOps.
Before adoption, qualify the actual artifact, supported client/server combination, consistent backup/recovery and postflight under an owned maintenance window. Do not start an older binary against a database at migration 72 (SQLite user_version 0). The protected shared-3010 maintenance requirements remain separate; no forced stop, client upgrade or OS update is authorized by this source check. #34 stays open.
Two independent native Opus 5.5 High / Fast off reviews accepted the bounded factual records after corrections. Private evidence: 60-file manifest 6db81aa67c1fc694814a10299509685ce0025ab1f3171d945573c81c230d0dab. This is not backend adoption or unattended-operation acceptance.
gustavonline commentedon Oct 28, 2026
Docker login recovery: restored manually; unattended renewal remains open
During qualification on 28 October, the operator observed native Docker CLI commands being rejected as “not signed in”. Reconnecting the existing account through the normal
sbx logindevice flow restored native inventory access. No new account, PAT or expanded access was created.Postflight showed the four baseline sandboxes running, with unchanged service MainPIDs. All four T3 webservers answered on their configured listeners and had matching binary hashes. Initial probes using the wrong address family were retained and followed by correctly addressed checks; no server restart or exposure change was needed. The old stopped sandbox named
arcitai-factory-lab-agentopsis retired; the active AgentOps runs inarcitai-factory-lab-t3.The cause of the lost CLI login and a reliable unattended renewal route are not established. This is a verified manual recovery, not completed automatic maintenance.
Owning-tracker status, rather than a result of this probe: #34 stays open; the shared 3010, client, OS and safe-update holds are unchanged.
gustavonline commentedon Oct 30, 2026
30 October 2026 — status: the Lab AgentOps on official Stable 0.1.5 has now delivered two reviewed documentation cycles in native Auto. These were PR #106 and PR #107 / v0.1.28, using fresh Stable 0.1.5 task workers. That covers the "useful model/review/delivery work from the restored Stable Ops" check, within these bounded cycles.
Some worker review attempts failed on model-API "No response" timeouts; the cause is not established. Still open here:
Released v0.1.28 AgentOps and Foundation skills are now installed in the Lab lead, matching the staged release byte for byte. Quota auto-resume, restart-resume and intake remain off.
gustavonline commentedon Oct 30, 2026
30 October 2026, 10:08 UTC: Factory v0.1.29 is released and installed for the Lab lead's AgentOps and Foundation skills. Its canonical Notion editions were updated first through the Notion Skills API. The three old baselines stay retired (stopped, disks kept). Still open here: clean manual stop (exit 125), unattended updater, boot/login and maintenance windows, whole-VM or new-VM restore. Quota auto-resume, restart-resume and intake remain off.
gustavonline commentedon Oct 30, 2026
Lab Ops restart for the #108 telemetry change — 30 October 2026 (UTC)
The first planned configuration restart of the Lab's Ops T3 service, done in the installed maintenance order, kept the same GUI, thread and history, and useful model work continued afterwards. The physical-host operator ran the host steps; the Lab AgentOps did the pause, baseline, readback and resume.
Sequence
factory-lab-native-control.targetfirst and let its helpers settle.T0was 14:20:47, taken on the guest clock.Still not qualified: clean stop (exit 125 remains), new-VM GUI restore, whole-host boot/login recovery, unattended updates and Docker-login renewal. This was one supervised restart with operator assistance, not unattended operation.