Skip to content

Rename Smalltalk to Fractal (product, binaries, crates, env, wire, state) #3032

New issue
New issue
Open
Open
Rename Smalltalk to Fractal (product, binaries, crates, env, wire, state)#3032

Description

@schickling-assistant
schickling-assistant
opened on Oct 15, 2026

Request

Johannes Schickling asks to rename the product Smalltalk to Fractal. The rename covers every layer: brand, binaries, crates, environment variables, wire identifiers, state directories and durable IDs. A legacy name may stay only for a fixed transition, and each legacy name has a tracked removal.

#1635 states that the smalltalk → fractal rename and the repository rename are not authorized yet, and that they are @myobie's decision. This issue asks @myobie for that decision. After acceptance, one dedicated agent carries out the rename, in phases, from this issue.

Current contract — Johannes Q31–Q34 (2026-10-30)

Approved accelerated full migration; this section controls where the older plan below conflicts. Axe request → approved answer handles: Q31 uka41s → 0fs63z; Q32 0qv9dz → j53xou; Q33 a0rtmu → zqthmb; Q34 2rj8iq → l4k2d7. Q30 remains binding: versioned new writes and permanent minimal read-only historical decoders; immutable history, old generations and published releases are not rewritten.

  • Q31 — completion is zero ACTIVE legacy names, not an alias rollout. The installed executable must physically be fractal, not a fractal symlink to st3; no active st/st3 aliases remain at done. Scope is the entire active execution, configuration, service, state/path, environment, API/wire, telemetry, package/module and reference surface, including downstream consumers and policy. Temporary compatibility is unfinished migration, never a completion exception. Historical immutable bytes and individually named, allowlisted minimal read-only historical decoders are the only legacy allowance; there is no active legacy-writer exception. The old “Not renamed” domain/schema rationale below preserves history, not permission to keep new active writes under old names; Q30 requires a versioned new-write transition with historical verification intact.
  • Q32 — readiness gates replace rename-only calendar waits. The 60-day/14-day/about-2026-11-01 windows and the .st/ fallback seven-day wait below are SUPERSEDED FOR TIMING ONLY. Remove bridges as soon as their real readiness and compatibility prerequisites are proven; do not wait solely for a date, and do not remove support merely because a date passed. Preserve accepting-reader-before-writer ordering, supported copy-only base compatibility, grant/history handling, receipts and other actual dependencies. Historical decisions, dates and evidence remain below for provenance, not as current calendar-only gates.
  • Q33 — checkpointed managed restarts are approved. The runtime owner may checkpoint and restart managed agents/services to adopt the cutover. Interactive terminals and unrelated user workloads remain protected; no indiscriminate kill/restart or safety waiver. Ownership, per-host Manager GO, Deployer T0, rollback and resource admission remain required. The Deployer (agent/dotfiles/deployer, or an operator it names) owns runtime/host cutover; the rename agent is preparer and receipt collector, not executor. No dev5 commands by the rename agent or its helpers. Earlier prose assigning dev5/dev3 execution to the rename agent is superseded by this owner boundary.
  • Q34 — execute the full approved outcome and narrowly update existing vision/requirements for exactly these outcomes. Physical executable, packaging/install paths, policy and actual host adoption are early priorities. Warn on deprecated st and st3 executable aliases #4274 is warning-only, not the binary switch, alias removal or proof of adoption; its former not-before-2026-11-01 warning date is superseded for timing only. Keep real downstream dependencies and outstanding host rollout explicit. No new product scope or rewriting of other owners’ documents outside their ownership path.
  • Done requires per-host adoption receipts plus an active-residue audit, across all scoped surfaces and downstream consumers, with every bridge contracted or explicitly allowlisted as historical read-only decoding. Source merge, a warning, a new symlink, or one host receipt is not fleet completion. This approval records no claim that any/all hosts are ready or complete; unchecked checklist items remain unchecked until their evidence exists.

Unchanged controls: existing owner STOPs remain binding, including PTY STOP 9accbcc7: no PTY pin/binary change. Deployer owns all host cutovers; no new checks are admitted by this approval. Existing resource/admission controls, protected interactive workloads, per-host GO/T0 and the serialized Mac Q27-then-TUI lane remain unchanged.

Physical-adoption owner clarification: Manager message/7f83f30162b1cbd0 withdraws the earlier daemon-pin-until-STOP/calendar interpretation: it prohibited opportunistic bumps, not physical #4445 adoption. CM message/82773930 confirms STOP 9accbcc7 covers PTY pin/binary changes, not a blanket daemon freeze. CM's corrected condition message/f699004680f48681 is no PTY bytes change on any host, separately for each deployed role—not host/bundled PTY equality. Preserve the documented smalltalkPtySkew: Deps message/2243b06b92ce4157 supplies host PTY 063ff7f9 SHA-256 21a772fe86cee219b4e84cebf5c657173c9b09be1fd71979a1fd24f5531cd953 and Fractal-bundled PTY 79d526d1 SHA-256 c94fdd6b394e52134f86b7bac4991450a0738e428f0b7b54a0e3574d9144161e. Compare each role's before/after digest independently and record both; removing existing skew is itself a PTY change. Under D1, a bundled digest different from c94fdd6b394e52134f86b7bac4991450a0738e428f0b7b54a0e3574d9144161e requires the PTY window; identical bytes use normal readiness. No complete store path is supplied by that receipt; do not treat its partial path as complete. Deployer owns read-only observation of which binary the running daemon actually executes and the full-path/digest receipts. Physical-only adoption requires Policy atomic adoption and Deployer normal readiness/admission, no overlapping daemon/checkpoint wave on that host, and dev5 mixed-version smoke before dev3; no separate Manager GO beyond these conditions. Any PTY byte change remains blocked by STOP until its authorized window. This records gates, not host adoption or a waiver of other scoped controls.

Observed PTY runtime is distinct from installed pins: CM message/04996f697386251a, from Deployer message/0e23104e, records about 09:00Z that three Linux hosts had installed daemon st3 v0.3.23. On two, long-lived daemon-spawned pty __daemon processes started 2026-10-20 still executed a third PTY build, observed only as partial prefix 7ef779bf…, neither the host nor bundled digest above; on the third, interactive sessions used three older PTY builds. That partial prefix is not a full digest or an accepted new-writer identity. Current rolls restart none of those PTY processes: pin bumps do not replace running processes. The PTY window plan must therefore include owner-coordinated checkpoint/session drain or restart of those PTY servers, with runtime observation/receipts; no restart or kill authority is granted here.

CM message/f31a68ba97d461d7, from Deps message/cdede090, further distinguishes execution roles: Home Manager starts the daemon with --pty-binary=cfg.ptyPackage (host pin; contextual baseline nix/hm-module.nix:27,57), so newer PTY servers use that host build; the bundled skew is shipped but not executed by that daemon path. Older 2026-10-20 third-build servers remain alive alongside them. The authorized PTY window plan must cover both pin adoption for new servers and owner-coordinated drain/restart of old long-lived servers; neither step proves the other.

Current owner-by-area execution and receipt plan — run 2 (2026-10-31)

Execution/receipt tracking under the controlling contract above, not new scope or completion approval. Source merges, isolated proofs and draft artifacts do not establish host adoption; existing checklist states and owner controls remain unchanged.

Active lanes: boot reader #4474 MERGED 818412302aacb809da807ebc6f1178a2c7627229 at 2026-10-31T12:53:32Z, reviewed head 9f9bcf1ac81b23517c4f9f1f86047ed27961905d; source GO, independent CM GO, U04 PASS and hosted receipt. Hosted proof binds tested merge-tree fallback, not standalone head-tree execution; historical draft 41200584229 all-31 SKIP remains nonproof. TUI #4482 is ENQUEUED, merge pending, exact ff554bf831a9cfc006a34d3f4c75e6dbf36b1e99/tree 40a1c2eb (prefix); focused proof: tests 2/2, Clippy exit 0/warnings, clean source throughout. Cold closure 140.45 s (91103:1793453896.927949); focused proof 246.32 s (95658:1793454039.601404), max RSS 2,403,418,112 bytes, swaps 0; owned target/outlink removed. First unsupported nix develop --dry-run pre-Cargo failure 43504:1793449989.114456 remains a plan error. Inspected draft Workspace 41207386432: all 31 jobs SKIP, zero steps, nonproof. Fractal rename agent flipped READY under CM 7f2/fedd receipts; post-ready Workspace 41207721720 SUCCESS, four required green, inspected hosted receipt: Linux/genie actual; TS/web enforced fleet/ci input-equivalent trusted notes, not fresh TS/web execution. Proof binds merge-tree fallback 1f0dc035/tree 9ad2d813 (prefixes), not source-head tree 40a1c2eb execution. CM handoff 35c1ad52a2a9430a followed by independent exact-head GO, U04 PASS and CM 2ff7ba5af1d08706 queue admission; no source change/carry or merge claim. CM owns queue follow-through. Draft slots only #4399/#4274. Q27 Nathan hold unchanged. Physical #4445 merged; release/tag/Policy/host adoption pending, no new release or host-adoption claim.

Owner key (literal ST_AGENT identities; short labels below): rename preparer = Fractal Rename (agent/compoundingtech/fractal-rename); CM = Compounding Manager (agent/compoundingtech/compounding-manager); Policy = Agent Policy (agent/dotfiles/agent-policy); Deps = Deps Manager (agent/dotfiles/deps-manager); Deployer = Deployer (agent/dotfiles/deployer); SDK = ST Graph SDK (agent/compoundingtech/st-graph-sdk); Attention = Attention (agent/dotfiles/attention); Fabric owner = Fabric-mesh (agent/dotfiles/fabric-mesh); Factory = Factory Manager (agent/dotfiles/smalltalk-graph); Product Lead = Fractal Product Lead (agent/dotfiles/fractal-product-lead); Disk owner = Disk Manager (agent/dotfiles/disk-manager); Manager = Manager/Chief of Staff (agent/dotfiles/manager). Nathan is the external upstream maintainer.

Area / owner Current artifact Next execution gate Required receipt / real pending decision
Physical executable / rename preparer, Policy, Deps, Deployer #4445 MERGED 4c0c6b77baf9f9adf9064e98cecee954edb5a458 at 2026-10-31T13:09:15Z, reviewed head 687332de0a9aac6352740e100d1e656fed6371ef, head tree cd108c9a8ee4d3b14bec61fb38b1d63f3892c7cd, parent 61bee5593577a8824f659877770a6302eafe7e4f. Signed S9 ownership-preflight fix preserves HM physical layout; local proof/content-equivalent Linux screening, CM exact 687 GO, 687 scoped hosted receipt and renewed U04 PASS. Prior 61bee U04 FAIL resolved at 687, retained as history, not relabelled. #4372 merged at reviewed head 496ca78114d8fb3517fe9b332cc4ef8a7686eca2. CM fedd0c231a6c023a: 2026-10-30 baseline advance hit Actions 403 (#3871), could not open PR; 2026-10-31 publish refused stale v0.3.22 baseline behind v0.3.23. CM opened workflow-generated baseline #4483, independent GO, U04 requested; next daily release follows merge. Deps informed. No release/tag claim. Hosted Linux/genie and Mac installer/helper are actual successes; TypeScript/web SUCCESS uses enforced fleet/ci full-wrapper input-equivalent trusted notes, not fresh TS/web execution. Earlier whole Release had an unrelated Darwin product build pending at observation, not whole-release PASS. Old 61bee scoped proofs retain cache/Mac-Clippy-waived-not-run scope; 727 native proof is not whole-new-binary execution/equivalence, incoming-main changes not retroactively covered. Old 02ebe7 RED, timer exit127 and watch-exit1/RunComplete-success remain historical; no retry. Canonical tagged three-platform release/pin, Policy atomic adoption and per-host Deployer receipts remain pending; source merge is not host adoption. CM owns release repair and fractal-first compatibility reader (contraction row); no duplicate worker. Manager cc313f8c via f33ca276 (accepted eb49db09): b5af 2026-11-01–11-02 proceeds, NO physical-release substitution; current sequence in state row supersedes earlier e107… substitution permission, not historical records. Preserve unchanged per-role PTY bytes/STOP, no-overlap/dev5-first fleet gates, actual running-daemon executable observation and physical executable/rollback receipts. No extra Manager GO, calendar daemon freeze or fleet completion.
Inputs and member names / Deps Canonical names: fractal, fractal-sdk, fractal-kit-dsl, fractal-native, fractal-messaging-baseline. Deps receipt prefix 37c2… accepts D1 actual-artifact delta inventory from b5af… to released physical tag for Manager. Input/member rename follows product/state adoption; canonical tag/pin must identify the adopted artifact. Policy receipt prefix a89…: no PR before release; one atomic PR on current main, not old 9f0…. Actual artifact delta inventory, canonical pin and consumer receipts; source/member naming alone is not rollout.
SDK, wire and durable tags / SDK, Registry, Product Lead CM receipt prefix 52ca13… confirms #4416 merged, reviewed head a4ebb98db917d3545e19ee666a2dd63c94e6ffc0; SDK owner 4e81844ac89a842c supplies merge 0ac8711cff29f6192aec9b7c9c872ed6eea3d417 at 2026-10-31T11:13Z, source only, not adopted. E1 #4479 exact fccc61937268f2d8424c0899f2b3ab92bfb203c2 is READY with independent GO, required checks running; five readers, fifth seat_freshness.rs found in review. SDK receipt prefixes 83f875…/f67af051…; accepted peer notice. Registry SCHEMA_NAME st3.v1 is hashed, distinct from peer tags. E1 five-reader PR checks/merge pending; R2/R3 readers follow E1, one code PR at a time. #4416/E1 do not gate physical #4445. They gate only matching SCG read-header/proof-domain writers and PEER_API_VERSION/envelope writers, after reader release/adoption across all members END; accepting readers → consumers → matching new writers with Product Lead review. Per-member accepting-release/consumer receipts before matching writer receipts; source readiness is not adoption or a writer switch. Registry-name Q428 + Nathan review remains separate; cryptographic inputs frozen pending decision, not active-writer completion. Do not conflate registry decision with accepted permanent peer decoder.
Attention tray and publisher identity / Attention, Policy Attention receipt prefix ae3030…: dotfiles#7943 draft, head d05574c79d8329b7e6dbbc6ee1f700b27c15a865, Mac build/Swift 10 PASS (comment 6542045485), not merged; not an stui wire consumer. Native R2 A/B already passed. dotfiles#7996 revert of #7810 must merge, then #7943 relands with green mr:lock-sync-check. R2 callsite waits for Policy #7968 merged plus actual canonical atomic adoption/R2 C. Policy receipt prefix a89…: readers already accept; only R2 C needs new proof in the single post-release atomic PR. Exact-head merge/mr:lock-sync-check and actual publisher/wrapper/canonical adoption receipts; build/Swift and A/B proof do not close R2 C or demonstrate rollout.
Fabric / Fabric owner Fabric receipt prefix f2d12…: A1 #4424 merged at d3c52841 (prefix); A3 #4429 merged cf0e2e8e6e434f531e7e77b375f6baa6d5494d9a; B2 #4439 merged 921d9922de066775c984601ffba4c5e5309604ac. R none: all registered members still old builds; X none. #3644 draft at 18eb5c94 (prefix), GO, waits for Nathan fabric#345 and v0.9.4. Owner 23ae8ede freezes exact unit pairs fabric-st.service/fractal-fabric.service, st-fabric-adapter.service/fractal-fabric-adapter.service and corresponding org.nix-community.home.* label pairs at dotfiles b8791c6123c1f129d3b11de7cbdd29704b4a2f66 / fractal 0fae408ebf41 (prefix). Fabric owns new fractal-fabric-adapter binary/package attribute; no implementation head yet, old attribute alias for one release, new binary not accepted before it lands and rolls. Source merges are not member R/adoption. D1 protects those exact names (forwarded to Deployer 7475becb/395814ac); Deployer 1d6c7a3ba7550bf1 reports D2/D3 dotfiles#8052 and D1 dotfiles#8053 merged (runtime row), not yet live per host. Writer D4 waits for readers live on every bundle host, not merely source merge; effective MemorySwapMax unchanged. Owner b9e96af86c2397ad confirms unchanged home/adapter state/st3 protocol/port list is this cutover only, not a permanent Q31 carveout. Plan 524897d9 owns identity-byte-preserving home move, reader-first protocol and exposure/grant/writer contraction; identity.toml canonical bytes, NodeID and frozen cryptographic domains never change. X requires dual exposure, exact grants and exercised dial; Q37 rotate in place, Q39 overlap ≤10 minutes. Released rekey prerequisite remains real, not a calendar wait. Actual per-member released tag/pin/build receipts for R, then dual-exposure/grant/dial receipts for X and Fabric T-minus/END receipts; adapter implementation/release/adoption remains pending.
Managed graph and agent identity / Factory Factory receipt prefixes 8ff091…/364b93…: P1 dotfiles#7955 merged 8e651094d8a820199a86536c5dd770bf499edfb4. Monitor/applier source consumers are only dev5, dev3, mbp2025 (home-manager/dev5.nix:242, home-manager/dev3.nix:801, home-manager/mbp2025.nix:344); monitor active dev5, dev3 SYS/mbp2025 rollout pending. dev4/mbp2021 are not monitor/applier consumers; prior dev4-active claim corrected. Factory tools land/attest on dev5 already dual-read (factory:580). Historical P5 receipt 465a08c2… at 1d476572905f188f5031ed8ab6f1f534c00c4f55 (+159/−15) reported dev5/dev3 all-three-phase evals, lint/registry/format/nixfmt/observability PASS and Factory-subagent source GO (not outside-Factory admission review). Owner 9e305f907d00f45b reported Deployer #7947 END dev5/dev4/dev3 at main a74f789b (prefix), releasing the Deployer-side #7999 merge hold, and Q390/non-Factory GO work at old 1d476572…. Current Factory b8a73131: dotfiles#7999 updated head ab0fe857fcacbb3df8844a508878114ac0b4eac4, graph-applier.nix:458–604; old-head proofs do not establish current-head Q390/GO, no Q390 PASS/READY/merge/rollout claim. P2 writer triggers only after those three actual consumers adopt 8e651094… or later. Independent FRACTAL_AGENT reader-gap work starts now: tools/commands/check.ts:138,269,281,320 and lib/missions/runtime.ts:58 currently read only ST_AGENT; lib/scratch-daemon.ts already reads both (factory:591). P5 uses explicit phase-mapped socket, else effective state-local published alias stateDir/run/st3.sock, not the actual binder directory; old/new unit After+Wants, selected Mac label query/no kickstart, literal ST_ACTOR=ST_AGENT=FRACTAL_AGENT, quiesce admission plus both locks/reconcile fence. This PR owns dev5/dev3 smalltalk-graph-applier-HOST.{service,timer,path}, smalltalk-graph-monitor-HOST.{service,timer}, smalltalk-graph-monitor-failure-HOST.service; Mac org.nix-community.home.smalltalk-graph-{applier,monitor}-mbp2025 unchanged in all phases. Later factory-* unit rename is a separate PR, no head yet, after dev5 daemon canary. Manager/Deployer receipt prefixes 7db70e9…/10f4bcb6…: #7999 joins rename-cutover lane once physical adoption plan exists; Deployer coordinates Q390/READY/merge timing with Factory, exact-head Q390 and independent GO not Factory-owned. #7947 wave END owner receipt above replaces that pending hold; no date wait. Fractal rename plan reference 29bab64817daab4f: tag → Deps pin/delta → Policy atomic adoption/R2 C → Deployer-coordinated runtime; target artifact/tag pending, no b5af substitution under current Manager sequence. #7999 remains in the coordinated adoption lane, not gated on #4445 source merge. Deployer coordinates READY/merge timing (3391d6c4ea59c5cd); no independent Fractal rename GO or host action. P3/P4 sites: gh.nix:38, checks/agent-policy-gh.nix:1703, ci.yml.genie.ts:533–539 insteadOf; GitHub ledger accepts both. URL PR starts now; skill counterpart not authored; resource hint dotfiles#7965 draft 28d4a252e16fda3be19bb50360ddba69e0cc9b1a. Actor rename retains upstream release/history/Axe gates; no identity recreation/history rewrite. Actual dev3/mbp2025 rollout and three-consumer/effective-identity receipts before P2 writer; reader-gap and actor-history/release receipts. P5 runtime packet must observe concurrent drain/first tick/Mac-label admission with abort criteria, actual endpoint-alias health at Deployer T0, quiesce-before/reconcile-after; these are pending steps, not prior proof. Coordinated admission routed to Deployer 7dc07339020f2f27 and Manager 531190aaeb948eb1. No extra Manager GO except Johannes-only mbp2025 activation. Source PASS/GO is not runtime admission, merge or rollout.
Clients and platform adoption / Product Lead Product Lead owner receipt 1b8dfed2031c2ae4: #4468 MERGED c2db4e96 (prefix), TUI accepts FRACTAL_PERSON/FRACTAL_ENDPOINT/FRACTAL_DOWNLOADS plus old names; dotfiles#7997 MERGED 2026-10-31T15:04:57Z (merge SHA not supplied), fractalite roster source label now fractal, Agent::is_fractal_seat accepts both fractal/smalltalk. Owner also reports rename Layer 3 #4404 MERGED ebcfc7d8 (prefix) and Layer 4 #4421 delta GO c7186509 (reviewed head prefix), checks running; no additional layer scope inferred. These are source-owner receipts, not proof of released/host adoption or a runtime writer switch. Separate TUI identity reader #4482 ENQUEUED, merge pending at signed ff554bf831a9cfc006a34d3f4c75e6dbf36b1e99, accepted 2/2 focused tests and Clippy exit 0/warnings (active-lane receipt above); post-ready Workspace 41207721720 SUCCESS/four required green with the execution-versus-trusted-note and merge-tree scope above. Existing TUI identity patch remains sole identity patch (fractal-tui, product directory tui). Web telemetry inventory not started. macOS identity PR 10 planned per receipt prefix 0ebc…, not a physical-binary blocker. Product Lead platform-specific compatibility review; preserve serialized Mac Q27-then-TUI lane. CM handoff 35c1ad52a2a9430a completed: independent exact-head GO and U04 PASS linked above, queue admission confirmed by CM 2ff7ba5af1d08706; CM owns queue follow-through, merge pending. Skipped draft checks are not execution proof. Source-label/env/path work does not add a physical-binary gate or establish platform adoption. Platform-specific compatibility/adoption receipts, including actual TCC grants where applicable; local focused PASS, source rename or isolated app proof are not host/device adoption.
State, disk and runtime / Disk owner, Deployer Movers #4303/#4308/#4354 merged; released tag and host-cutover receipts not supplied. dev3 dataset 42.6 GB plus growth; product root first, no mounts. Deployer owner 1d6c7a3ba7550bf1: D2+D3 dotfiles#8052 MERGED 2026-10-31T22:20:09Z, main 5b3850cf (prefix); D1 dotfiles#8053 MERGED 2026-10-31T22:21:05Z, main f822729c (prefix). Sources not yet per-host live. Separate store move requires disk/growth admission first. Controlling Manager cc313f8c via f33ca276, accepted eb49db09: b5af 2026-11-01–11-02 proceeds, NO substitution. R dev4 rehearsal (no peers) → dev5 FIRST FLEET canary → dev3 after dev5 smoke → Macs; mbp2025 Johannes-only. Deployer plans b5af HM/SYS wave in that order, Macs later; actual per-host receipts pending. R packet requires github-app-auth phase-fix exact head plus legacy/stage/completed evaluation receipts before any completed roll (af5c257a); prerequisite row below remains open. D4 writers wait for readers live on every bundle host. This supersedes earlier e107… physical-release substitution permission in current execution gates; historical records retained. No additional calendar-only R wait. Inventory schema/behaviour changes and flag schema/irreversible changes for Manager OK. Preserve trim.local #7990, #7947, per-role unchanged PTY-byte STOP and dev5 smoke gates; no #7988 delay past 2026-11-02. Only Deployer (or named operator) cuts over after per-host Manager GO/T0, with rollback/resources protected. Released mover+fix artifact and actual delta inventory; per-host state/service/physical adoption, effective MemorySwapMax/FABRIC_HOME, dev5 canary archive/removal and rollback receipts. No rename-agent dev5 commands or cutover completion claim.
GitHub App token publisher/check prerequisite / github-app-auth owner, Deployer, Factory Owner 729c2240: dotfiles#8034/#8038/#8041/#8043 stack adds user unit st3-github-app-token-publish with Before/WantedBy=smalltalk.service; smalltalk-app-token-root looks up the old daemon unit. Completed phase therefore fails the check/lacks daemon ordering. Owner follow-up has no PR/head yet. Follow-up before any completed host: consistently map publisher and check via existing config.services.smalltalk.fractalMigration.phase (legacy/stage → smalltalk.service, completed → fractal.service); no identified effectiveDaemonUnit export. Fractal rename request f9859404 requires publisher/check tests for all three phases; Deployer packet gate af5c257a, Factory coordination 7545b883. Exact follow-up head and exercised three-phase publisher/check receipts before completed-host admission. No T0 scheduled or adoption claim; stack rollout dates are not T0. Active legacy publisher/check names remain tracked for later contraction; this phase fix is not zero-active completion.
PTY / CM and Nathan owner/release routing STOP 9accbcc7; host 063ff7f9d6ef099f76c31752b2eb52c5bba94c17 and documented bundled 79d526d1 skew preserved, with separate full SHA-256s above. HM daemon --pty-binary selects the host pin for newer servers, not the shipped bundle; older third-build servers remain live alongside. Per CM message/7ffaf601a758ad2c and owner follow-up, restart identity scrub is fixed upstream in pty#178 (e237afa8, merged 2026-10-19), included in v0.13.0-rust.5 (2026-10-30), not frozen 063ff7f9; no source worker needed. st3.start-operation accepting reader has no upstream PR/accepted design; Nathan (b) unanswered, CM routes after answer, no worker started. STOP unchanged: no PTY pin/binary/bytes change in either role on any host; not a blanket daemon freeze or cross-role equality gate. Scrub adoption requires Nathan (a′) pin approval and the real 2026-11-03–11-10 STOP window. A changed bundled digest requires the PTY window; identical bytes use normal readiness. Window planning covers both pin adoption for new servers and owner-coordinated checkpoint/session drain or restart of old servers, not automatic process replacement or restart authority. Accepting-reader/new-writer ordering and immutable binding/revocation safeguards remain required. Separate before/after host and bundled full-path/SHA-256 receipts plus Deployer's actual daemon/PTY executable observations; new-server pin and old-server session/process receipts, with approved pin and exercised live restart/identity/publication proof. Upstream fix is an attributed owner receipt, not replayed verification or runtime completion.
Config, downstream and final contraction / Factory, downstream owners, Policy, CM release owner #4086/#4315 merged; #4399 draft f0f06fb35fff3b5459b3064e0de4ea03882c9ead. Dotfiles #6860/#7750/#7773 parked for CI admission; #4274 warning-only, readiness-aligned rewrite needed. scripts/compat-baseline-release currently selects smalltalk-<target>.tar.gz; v0.3.23 ships both smalltalk/fractal assets. CM 861bc94d9095cce6 confirms ownership of fractal-first reader in existing release-owner lane after #4483 and next release land: prefer fractal-<target>.tar.gz, fallback to smalltalk for retained releases; no Fractal rename worker. Old-asset producer contraction requires that reader MERGED AND one baseline advancement exercising it. Immutable old releases unchanged. #4399 signoff/risk/window/hosted gates pending; contract only after all consumers/copy-only bases/grants/history covered, no date-only wait. Exact-head owner/gate and exercised baseline-reader receipts, downstream/peer adoption, then zero-active-residue audit; only individually listed historical read-only decoders allowed. Reader ownership/schedule is not implementation, release or contraction completion.

Separate Darwin prestage repair: #4454, reviewed head prefix 40725b64, has source GO, U04 PASS and four actual required hosted successes. Merged 2026-10-31T08:48:23Z, merge 4bc521b3ab2a0a42822c05c3d4773503e5e657f0; #4448 auto-closed at 08:48:25Z (CM message/50f9642a, verified by Fractal rename agent). No close action needed. This remains separate from, and not a prerequisite for, #4445.

Q35 verification record, not a new principal/scope ask: CM message/a27e2b7fe0b13223 supplies Axe request 13uia6 (Compounding Manager store, parent z07vw0), Johannes answer mb8n4x, choice note-or-run. Trusted note OR CI run counts green at the exact head; gate SKIP counts only with a trusted fleet/host/agent key on main covering that head tree, citing the gate decision line/note, not a run. The merge queue full run remains final proof. Routing is unchanged: CM queue only, after independent exact-head GO, Janitor U04 PASS, four required green gates under Q35, MERGEABLE and non-draft; no author self-merge or delegated merge. This is not blanket draft-SKIP green and does not weaken zero-active completion.

Decisions from Johannes Schickling — historical decisions (current Q31–Q34 contract above takes precedence)

  1. Scope: full sweep. Not only the repository, README, docs and display names. Also the binaries, the 18 st-prefixed crates, the ST_*/ST3_* environment variables, the x-st3-* headers and the st3.client.v0 API version, the custom.st3.* claim kinds, the state directories (~/st, ~/.config/st3, ~/.local/state/st3), the service and launchd labels, and the Apple bundle and keychain IDs. Durable identifiers move through a live migration with dual-read, not a fresh namespace.
  2. "Fractal" is the product name. Every client is part of Fractal:
    • fractal with no subcommand opens the TUI. It is the short form of fractal tui, in the same way that pty opens its TUI.
    • fractal web serves or opens the web client (today apps/fractal-web).
    • The person CLI subcommands move under fractal (for example fractal work ls, fractal agents …).
    • stui and st3 are folded into the one fractal binary, or kept only as transition aliases.
  3. Transition: fractal plus a time-boxed st alias. st (and st3, stui) stay as aliases for a fixed number of releases. Readers accept the new and the old environment variable names during the same window, as in Use st-owned harness environments and shared record labels #874 (ST2_* → ST_*). Every alias ends on a stated date or release.
  4. No long-term legacy. Every compatibility bridge carries a structured marker (the existing arn:lmig: live-migration bridge markers) and appears in the checklist below with its sunset. Contraction is done when zero markers remain and no legacy writer is live. Permanent decoders for signed history are the only exception, and each one is listed by name.

Identifier classes — original transition inventory (Q31–Q34 completion/readiness contract applies)

Class Today Proposed Transition
Repository compoundingtech/smalltalk compoundingtech/fractal GitHub redirects; update installer and links
Binaries st, st3, stui fractal (fractal = fractal tui, fractal web) st/st3/stui aliases until sunset
Crates st3*, st-*, st2* fractal* source-only, no alias
Env vars ST_AGENT, ST_SUPERVISOR, ~45 ST_*/ST3_* new names (to decide) dual-read until sunset
Wire st3.client.v0, x-st3-*, st3.cap.* new names (to decide) server accepts both until sunset
Claim kinds custom.st3.* new names (to decide) live migration; history decoder kept
State dirs ~/st, ~/.config/st3, ~/.local/state/st3 new names (to decide) live migration with receipts
Services smalltalk.service, st3.service, com.compoundingtech.st3* fractal* install and remove in the same apply
Apple IDs com.compoundingtech.smalltalk.*, SmallTalk.app com.compoundingtech.fractal.* keychain migration per device
Packages @smalltalk/*, @st3/sdk, St3Client @fractal/*, FractalClient source-only
Evidence URI https://smalltalk.dev/evidence/gate/v1 to decide old URI stays readable
Releases smalltalk-<target>.tar.gz, "Smalltalk tag release" fractal-<target>.tar.gz installer reads both for one release

Decisions

Authority (Johannes, 2026-10-16, recorded by Compounding Manager): Nathan agreed to the full rename and reviews on his own time. Scope is the full sweep, including the durable layers; no downtime and no breakage: old and new names both work through each transition, with arn:lmig: markers, sunsets and per-site receipts. The rename agent decides R2–R6 and R8–R16 and records the choice and reason here. This replaces the earlier routing to Factory and Intake.

One row per decision. A phase starts only after its decisions are recorded here.

ID Decision Status
R1 Product name is Fractal accepted by Nathan, 2026-10-15 (comment); name only, starts no work
R2 Visible-layer acceptance decided by the rename agent, 2026-10-16: A (docs/brand, repository rename, fractal-* release files, one fractal program with aliases). Reason: full sweep; each part is additive or redirected, so nothing breaks. The repository rename is the last visible step (see R3). (ask) Factory agrees: A (6219734161); the repository rename needs an admin, asked at the end in an empty queue.
R3 Merge-freeze window decided by the rename agent, 2026-10-16: no freeze window (as Factory proposed in 6219572143). Additive steps first; script-generated, idempotent, rename-only PRs, landed one at a time to spare CI; source-path renames wait until the crate breakup (#3084 and the R0b splits) lands; the repository rename is one action in an empty queue, followed by a merge-main pass. Reason: no breakage and the least conflict for other owners. (ask) Factory agrees (6219734161): no freeze; rename PRs enter the merge queue one at a time; Factory moves each to the front once green with an exact-head review.
R4 Phase order and human gates decided by the rename agent, 2026-10-16: order: (a) fractal program with st/st3/stui aliases; (b) docs and brand; (c) env and wire dual-read; (d) crates and packages after #3084; (e) durable live migrations (R10–R14, R16 subject) with per-site receipts; (f) release file names and repository rename; (g) contraction at the R5 dates. Gates: each PR merges only with green required CI and an independent GO at the exact head SHA, both recorded in the PR; each migration needs a receipt per site; R7 holds rollout to Johannes's hosts. Reason: the program must exist before docs name it, and dual-read must be live everywhere before any writer switches. (ask) Factory agrees on the order (6219734161).
R5 Alias window decided by the rename agent, 2026-10-16: A: a date, 60 days after the first release that ships each bridge (the fractal program for the aliases; the bridge's own release for env, wire and storage bridges). Reason: releases are daily, so a release count is days; 60 days lets other fleets and repositories move without breakage. (ask) Factory agrees: A. Amended by Johannes, 2026-10-18 (q1, q4, q11): 14 days, not 60, and a hard date for every bridge whatever the adoption status, including the st alias and ST_AGENT. The bridges in edge bd8a368b (2026-10-18) contract on about 2026-11-01.
R6 Behavior of fractal web decided by the rename agent, 2026-10-16: C, built as B first (fractal web opens the configured or default web URL), then A (serves the bundled web client locally). Reason: B is additive and ships with the program; A needs the Node server logic in the binary and comes later. (ask) Factory agrees: C in two steps.
R7 Overlap: the existing fractal TUI program decided by Johannes (unchanged by the full-sweep decision) (ask). Johannes answered (relayed by Fractal lead, 2026-10-16): this repository owns the fractal name (bare fractal, fractal tui, fractal web); the dotfiles TUI stays in schickling/dotfiles and is renamed to fractalite, with no fractal alias; upstream may absorb it later. This replaces the Fractal lead's earlier option-A position (comment). Factory confirms (6219734161). Installer rule: never overwrite a fractal it did not install; link fractal only when the name is free, otherwise print what to do and leave st working.
R16 Overlap: "Smalltalk Assistant" decided by the rename agent, 2026-10-16: A now, B later: display name "Fractal Assistant" in the visible step; subject agent/st/assistant → agent/fractal/assistant and its workspace move in the durable phase as a seat-identity live migration with receipts. Reason: full sweep without breaking the running assistant's mail and claims. (ask) Factory answered A (display name only) before the full-sweep follow-up; the subject move stays in the durable phase and goes to Factory for review with the R10–R14 PRs. Amended by the rename agent, 2026-10-20: the subject move (B) is dropped. agent/st/assistant stays as a stable identifier, the same as every other agent/... seat ID, which the rename does not change. Reason: no replicated subject-successor operation exists that routes old mail and transfers subject-fenced capabilities and pending work while immutable claim history is preserved. Building one would be new product scope, and a partial move would break the running assistant. The display name "Fractal Assistant" (A) remains.
R8 Contract: environment variable names decided by the rename agent, 2026-10-16: B: FRACTAL_* (FRACTAL_AGENT, FRACTAL_SUPERVISOR, FRACTAL_BIN, …). Writers set both names; readers prefer the new name and fall back to the old one (existing legacy_env_name/env_with helper); external consumers (dotfiles agent policy, hooks, skills) get briefs; writers stop setting ST_* at the R5 date. Reason: full sweep; the product-name prefix matches the #874 precedent; a short prefix such as FR_ is ambiguous. (ask) Factory review conditions (6219753008): if old and new are both set and differ, the daemon reports the conflict and uses neither for identity; anything that sets or clears the identity variable does both names; external briefs before writers stop the old names.
R9 Contract: wire version and headers decided by the rename agent, 2026-10-16: B: fractal.client.v0 accepted as an alias of st3.client.v0; x-fractal-* headers and the fractal.cap. prefix accepted beside x-st3-*/st3.cap.. Servers accept both first and keep sending the old names; clients and peers send the new names only after every fleet host runs the accepting release. No v1: the contract does not change. Reason: full sweep without a mixed-version break. (ask) Factory review conditions: switch senders only after every member is recorded on an accepting release; paired-device grants hold capability names, so the old st3.cap. prefix stays accepted until each grant is re-issued (permanent decoder if a grant can outlive the window); contract files change in one PR with an old-client test.
R10 Storage: claim kinds decided by the rename agent, 2026-10-16: B: readers project custom.st3.* and custom.fractal.* as one kind; after every host reads both, writers write custom.fractal.*. Signed claims are never rewritten. The old-kind reader is a permanent signed-history decoder (exception listed by name in this issue). Reason: full sweep while signed history stays valid. (ask) Factory review conditions: the new kind keeps the same specification, retention class and cardinality; writers switch only after a recorded fact that every member reads both (otherwise graph digests diverge).
R11 Storage: state directories decided by the rename agent, 2026-10-16: C, staged: config and state move first (~/.config/fractal, ~/.local/state/fractal, ~/.fractal-instance/NAME) by a per-host stop-copy-verify-start with a receipt; the daemon reads the new path and falls back to the old one until the R5 date. New seats get ~/fractal/agents/IDENTITY; an existing seat's workspace moves only while it has no live session. Reason: full sweep; running seats and native resume do not break. (ask) Factory review conditions: same filesystem = rename with the old path left as a link; across filesystems copy after a free-space check; keys keep permissions; a moved marker makes the daemon refuse the old place; the old socket path stays reachable for running sessions. Cutover mechanism, Johannes 2026-10-18 (q8, q10): pre-staged swap, not copy-verify. Home Manager installs the disabled fractal.service outside the gap; a per-host script runs stop → mv st3 fractal (and config) → receipt → symlink st3 -> fractal → start → API probe. Measured gap about 1–2 s on dev3 and dev5 (limit: 5 minutes per host). Live drivers keep absolute old paths (driver_cli.rs:648-655, 2215-2241), so the symlink bridges them; seats move on re-exec, and the remaining seats are re-executed before the symlink is removed on the hard date. Prerequisite on dev3: ~/.local/state/fractal holds the dotfiles TUI's presentation state and moves to fractalite with R7 first.
R12 Storage: service and launchd labels decided by the rename agent, 2026-10-16: B: fractal.service, fractal-replication.service, com.compoundingtech.fractal*; Home Manager fractal.service/fractal-apply. One install or apply writes the new unit and removes the old one in the same step; the installer refuses if both exist. Receipt per host. Reason: full sweep; never two daemons on one state directory. (ask) Factory review conditions: one host at a time, not during a checkpoint or sync. Factory addition (6220163738): the daemon's memory-protection drop-ins (MemoryMin/MemoryLow, swap limit) are keyed on the unit name, so the same apply moves the whole .d directory, and the per-host receipt checks effective memory.swap.max and MemoryLow afterwards; Factory supplies that check in the apply script.
R13 Storage: Apple bundle and keychain IDs decided by the rename agent, 2026-10-16: B, staged: first the current apps ship a shared keychain access group (additive); then com.compoundingtech.fractal.* apps read the old keychain items and copy them under the new service, so devices keep their fleet identity. The old app stays until each device has a receipt. Johannes re-grants TCC permissions on each Mac (human step). Reason: full sweep without re-pairing devices. (ask) Factory agrees with the staged plan. Replaced by Johannes, 2026-10-18 (q6): re-pair devices. New com.compoundingtech.fractal* bundle IDs, one install per device, re-pair, revoke the old keys, no keychain copy. The flow is untested; it is proven on one device first.
R14 Contract: evidence predicate URI decided by the rename agent, 2026-10-16: B: a Fractal-domain predicate URI; the verifier accepts both first, then the signer writes the new one; the old URI stays accepted as a permanent signed-history decoder. (ask) Factory review conditions: the verifier release that accepts the new URI is on the base branch before any PR is signed with it; the old domain stays owned. URI chosen: https://compounding.tech/fractal/evidence/gate/v1 (domain from Johannes, 2026-10-16, via Compounding Manager). Verifiers accept both URIs permanently; old signed attestations stay unchanged; whether smalltalk.dev lapses is a separate decision.
R15 Crate and package renames (source only) decided by the rename agent, 2026-10-16: A: fractal* crates, @fractal/* packages, FractalClient; no aliases (source only). Starts after #3084 and the R0b splits land. External users of the generated clients get a brief first. Reason: full sweep; nothing persisted uses these names. (ask) Factory agrees: A, after the crate breakup. Johannes, 2026-10-18 (q7): full rename now (about 6–8 PRs); the rename agent helps the open PRs of other authors adapt after each crate rename.

Authority and plan (Johannes, interview 2026-10-18) — historical; calendar-only timing SUPERSEDED by Q32

Recorded in the rename agent's Axe decisions q1–q11.

  • Merge gate (q2): Nathan permits self-merge of every rename and migration PR in this repository (source: Johannes, 2026-10-18). No Intake gate. Each PR needs green required CI at the exact head, an independent reviewer GO at that head and an evidence comment, then gh pr merge --match-head-commit <sha>, never auto-merge. Other repositories keep their own merge routes (dotfiles: the dotfiles merge queue with a lander SOURCE GO and an exact-head receipt; Agent Policy reviews every instructions, skills and policy-guard PR well before 2026-11-01).
  • Done (q1): landed and adopted downstream, then contracted on the R5 dates.
  • Throughput (q3): at most 2 rename PRs of this repository in CI at once; a light cargo check before each push.
  • Downstream (q5): the rename agent writes every downstream change (dotfiles, smalltalk-graph, effect-utils, pty, the private website), including the gaps the bridges do not cover; the owners review. Archived repositories and the stale convoy-rust are out of scope.
  • Repository rename (q9): Johannes or Nathan renames compoundingtech/smalltalk → compoundingtech/fractal (name free) in an empty queue at the moment the first crate-rename PR lands; then the rename agent runs one merge-main pass across the open PRs.
  • Speed-ups (Johannes, 2026-10-19, q12–q14): R15 is one mechanical PR for every crate and package (not 8), landed together with the repository rename after fix(replication): retain structured last failed exchange diagnostics #3443. Rename PRs push CI-first, without a local heavy-slot wait; CI is the authority. Per-host cutover: the rename agent runs dev5, then dev3; dev4 goes through the deployer; Johannes is present for mbp2021, then mbp2025. Chief of Staff helps with deployer windows, the pin bump and Agent Policy review.
  • Order: finish the bridges (R8 part 3, R9 sites, R11/R12 installers) → R7 dotfiles chore(nix): pin mergemaster to v0.6.0 #6224 → R15 crates with the repository rename → per-host cutover (R11/R12) → switch senders (R9), signer (R14), R16 subject, release names, R13 re-pair → downstream switch of instructions, skills, policy guards and pty; seats reload → contraction on the hard dates.

Open questions (to settle before implementation)

All settled; see the Decisions table and the section above.

Original list
  • New environment variable names: FRACTAL_AGENT/FRACTAL_SUPERVISOR, or a short prefix.
  • New wire version: rename to fractal.client.v0, or start fractal.client.v1.
  • Alias window: number of releases or a date.
  • fractal web: serve locally, open a URL, or both.
  • The evidence predicate URI and domain.
  • The order of phases, and which phases need a human gate.
  • Overlap with other names: "Smalltalk Assistant" (Rename the first agent to the Smalltalk Assistant #2520) and the fractal client class.

Proposed phases — historical sequence; Q31–Q34 readiness/ownership contract applies

  1. Accept the rename and settle the open questions here.
  2. Brand, docs, repository rename, release artifacts.
  3. One fractal binary with tui/web subcommands, plus st/st3/stui aliases. Rollout condition (R7): the upstream fractal program must not reach Johannes's hosts until the dotfiles rename PR (fractal → fractalite) has landed. The Fractal lead posts that PR link here. Dotfiles rename PR: dotfiles#6224, merged 2026-10-19.
  4. Crates and generated client packages (source-only).
  5. Environment variables and wire identifiers with dual-read.
  6. Live migration of state directories, claim kinds, services and Apple IDs, with per-site receipts.
  7. Contraction: remove every alias and bridge, and confirm zero arn:lmig: markers for this rename.

Legacy removal checklist

One item per bridge, filled in as bridges are added: identifier, marker slug, sunset, removal PR. Calendar-only sunsets/waits below are SUPERSEDED FOR TIMING ONLY by Q32; real compatibility dependencies and evidence remain required. No checklist status is changed by approval.

  • st/st3 binary aliases · marker arn:lmig:smalltalk:2026-10-16-fractal-binary-aliases · sunset: about 2026-11-01 (14 days after edge bd8a368b) · bridge PR: Rename: add the fractal program beside st and st3 #3226 (merged) · warning PR: Warn on deprecated st and st3 executable aliases #4274 (PARKED, draft; branch retained; parking receipt; warning-only, not a binary switch or alias removal. Existing warning promises removal on 2026-11-16, contradicting Q31–Q34 readiness; cannot land unchanged as the binary switch. Reissue warning aligned with executable-first readiness and downstream stderr-consumer adoption, with new exact-head proof and review; no close, source push or CI rerun. Former not-before-2026-11-01 gate SUPERSEDED FOR TIMING ONLY by Q32; dependency dotfiles#7817 merged in source 2026-10-30, host rollout still pending on dev3 and mbp2021) · removal PR: pending. (stui is not an alias: main already removed the standalone stui executable before the rename; st ui opens the TUI.)

  • ST_*/ST3_* environment variable dual-read and dual-write · marker arn:lmig:smalltalk:2026-10-16-env-fractal-dual-read · sunset: about 2026-11-01 (14 days after edge bd8a368b) · bridge PRs: Add Fractal environment bridge at shared provider boundary (R8 part 1) #3233 (part 1, shared provider boundary, merged 2026-10-17), Extend Fractal environment aliases to daemon and CLI identity (R8 part 2) #3265 (part 2: daemon/CLI/clap/Codex, merged 2026-10-17), part 3 (shell, TS hooks, installers, Nix, CI, iOS): feat(env): FRACTAL_* dual-read in shell and TS hooks (#3032 R8 part 3) #3432, merged 2026-10-19 (the st3-daemon hook assets read no ST2_*, by the fresh-seat boundary) · removal PR: pending. Remaining real downstream dependency — PTY restart identity scrubbing: Fractal rename agent directly inspected exact frozen PTY 063ff7f9d6ef099f76c31752b2eb52c5bba94c17: cli/mod.rs:111 scrubs only ST_AGENT, ST_ROOT, AGENT_TRACE_FILE; lifecycle/launch.rs:824–831 inherits caller environment and removes only scrub keys; daemon/env.rs:93–181 inherits unless replacement/isolation applies, then overlays session_env/unset_env/extra_env. Ambient FRACTAL_AGENT/FRACTAL_ROOT can therefore leak into restart/attach/picker when saved settings do not override/remove them. This is source-inspection evidence, not runtime proof; the earlier assumption that PTY is unrelated is corrected. Upstream fixed, adoption pin-gated: per CM message/7ffaf601a758ad2c and owner follow-up, pty#178 merged as e237afa8 on 2026-10-19; release v0.13.0-rust.5 (2026-10-30) includes ST_AGENT, ST_ROOT, FRACTAL_AGENT, FRACTAL_ROOT, AGENT_TRACE_FILE in cli/mod.rs:111 on main 395e80cf. Frozen 063ff7f9 does not include this fix. This attributed owner receipt does not replace the frozen-pin inspection or claim a new upstream replay/runtime proof. No source worker needed; adoption requires Nathan (a′) pin approval, the real 2026-11-03–11-10 STOP window, per-role before/after byte receipts and exercised live restart receipts covering old servers. STOP 9accbcc7 remains binding: no PTY pin/binary change or host action. Prior CM owner/release routing: message/af97cd45967b1874.

  • x-st3-* headers, st3.client.* protocols and st3.cap.* accepted by receivers next to x-fractal-*, fractal.client.* and fractal.cap.* · marker arn:lmig:smalltalk:2026-10-16-wire-fractal-accept-both · sunset: about 2026-11-01 (14 days after edge bd8a368b) · bridge PR: Accept Fractal wire aliases before sender cutover #3239 (core handshakes and headers, merged 2026-10-17); remaining receiver sites: feat(wire): accept fractal.* names at remaining receivers (#3032 R9) #3430 (merged 2026-10-19; senders unchanged, cryptographic domains and the signed peer envelope tag st3.v1 unchanged) · removal PR: pending.

  • Evidence signer writes https://compounding.tech/fractal/evidence/gate/v1 · marker slug evidence-predicate-uri · bridge PR: Accept Fractal evidence predicate URI before signer cutover #3234 (merged; the verifiers accept both URIs) · signer switch: feat(evidence): switch gate signers to Fractal predicate URI (#3032 R14) #3577 (merged 2026-10-20). The verifiers accept the old URI permanently; there is nothing to remove.

  • old state directory readers · marker arn:lmig:smalltalk:2026-10-16-state-dirs-fractal · step 1 (readers select a Fractal directory only with the migration receipt): Prepare daemon directory readers for Fractal state migration #3247 (merged; the edges st3-kernel and st3-telemetry -> st3-client for product_dirs are part of this bridge and go away at removal) · hardening: Refuse migrate host when a product root is a mount point #4292 (merged; mount refusal), Allow a separately configured claims database directory #4303 (merged 2026-10-30; store_dir), fix: respect explicit store directories in host migration #4308 (merged 2026-10-30; store-aware mover) · Mover source fix merged; released-artifact readiness still pending: Fractal rename agent direct PR snapshot records fix: preserve replication aliases and systemd control drop-ins during migration #4354 merged 2026-10-30T18:11:55Z, merge ee88267d7fed3f64afac3d58277a719b971962f1, reviewed head 6c672c4b3d3f399abec6af5e0e36acb636105251. Fractal rename agent latest-release snapshot still shows v0.3.23, published 2026-10-30T11:23:46Z, target 943445316e3738a1fc1ee58f676334b7ec684bf4; this predates fix: respect explicit store directories in host migration #4308 merge 8b318299 and the fix: preserve replication aliases and systemd control drop-ins during migration #4354 fix. A released artifact containing both the store-aware mover and its fix is a remaining real canary dependency; source merge alone is not artifact readiness, host adoption or canary GO. Deployer notified via message/91d10ff487b749e0; Deployer remains executor and the rename agent remains preparer/receipt collector. No whole-host/mover readiness is marked done and no calendar forecast is a readiness gate · per-host migration runs with receipts: pending (no host has a receipt yet; dev5 canary executor: the Deployer, agent/dotfiles/deployer, or an operator it names — the rename agent only prepares and collects receipts and runs no dev5 commands; per-host Manager GO and Deployer T0 mandatory) · removal PR: pending

  • old service and launchd labels · marker arn:lmig:smalltalk:2026-10-16-service-labels-fractal · step 1 (lookups accept both names; a legacy unit plus a Fractal unit is a hard error): Accept Fractal names in native service lookups (R12 step 1) #3249, merged 2026-10-17 · step 2 tooling: feat(migrate): pre-staged per-host fractal cutover (#3032 R11/R12) #3435, merged 2026-10-19 (fractal migrate host: pre-staged swap with journal, rollback, receipt, st3 -> fractal symlinks, drop-in move, memory check; Home Manager stage/completed phases and a fence against forced legacy generations) · per-host runs with receipts: pending (executor boundary as the state-directory row: the Deployer, agent/dotfiles/deployer, or an operator it names runs the dev5 canary; the rename agent prepares and collects receipts only; per-host Manager GO and Deployer T0 mandatory) · removal PR: pending

  • old installer artifact names · markers arn:lmig:smalltalk:2026-10-20-release-artifact-aliases (install.sh, scripts/release-fractal, scripts/release-fractal-manifest.py, docs/st3/binary-releases.md; PR Publish Fractal release archives with temporary Smalltalk copies #3578) and arn:lmig:smalltalk:2026-10-26-release-artifact-name (scripts/release-fractal-daily; PR fix: finish Fractal release and tooling rename residue #4028). Releases publish the Fractal archives plus temporary smalltalk-<target>.tar.gz copies · sunset: about 2026-11-01 · removal PR: pending.

  • Script path bridges · marker arn:lmig:smalltalk:2026-10-27-script-paths · bridge PR: fix: finish Fractal script path renames #4089 (merged 2026-10-28). Five old scripts/st3-* names forward to the scripts/fractal-* implementations, because installed units, the plist and copy-only readers still call the old paths. The bridges keep their original file modes · sunset: about 2026-11-01, after the units and the plist call the new paths · removal PR: pending.

  • Repository config directory .st/ → .fractal/ (Q27, answer 5i9b8z) · marker arn:lmig:smalltalk:2026-10-27-dot-fractal-config · plan: comment 6445632509. Step 1, readers prefer .fractal/ and fall back to .st/ at the same pinned revision: Expand evidence configuration readers to .fractal (Q27 PR1) #4086 (merged 2026-10-30); hard-order condition test: finish preferred-first config reader follow-up #4315 (merged 2026-10-30, before any .fractal/ config files exist). Dotfiles signer retired on dev5 and dev3 (receipts). Step 2, move the files: #4399, draft, exact head f0f06fb35fff3b5459b3064e0de4ea03882c9ead: 14 byte-identical moves, two required-lanes definition-path updates and regression coverage. Native workspace check, three kernel tests and focused integration PASS; parent-genie check and source equivalence PASS; baseline affinity failure disclosed. Factory signoff, risk/window approval and actual hosted gates remain pending; source proof is not host adoption. Step 3, remove the fallback: pending; the former seven-day wait is historical and SUPERSEDED FOR TIMING ONLY by Q32. Current gate: evidence for all supported copy-only bases/readers and peer adoption, then owner-controlled contraction; no new day-based wait.

  • Residue found by the 2026-10-28 deep scan · visible text, tool names (st3-client-codegen → fractal-client-codegen, st3-fixture, FRACTAL-PATCH.md, check:fractal-coverage) and env fallbacks for names that had only an old form (ST_IOS_*, ST3_BLOB_RETENTION_HOURS, ST3_GITHUB_API_URL, the daemon caps, STUI_*): fix: complete scoped Fractal residue cleanup and env bridges #4140 (merged). Downstream: effect-utils#2173 (merged), dotfiles#7773 (parked, waiting for the ci-manager slot after #7810), and a brief to the smalltalk-graph agent for text, links and the genie-fractal repin. Still open: the st3-migrate executable bridge (installed through scripts/install and flake.nix); the @smalltalk/st3-client and @st3/sdk packages in dotfiles webfractal; and a keep-or-migrate decision for st-sekrets.service, the st_tiles* slices, the st3-pty-server-* scopes, the old flake attrs and services.smalltalkReleaseDelivery. Remaining real PTY publication dependency: Fractal rename agent exact-object inspection at frozen 063ff7f9d6ef099f76c31752b2eb52c5bba94c17 found active st3.start-operation readers in registry/mutate.rs:198 and lifecycle/config.rs:81,100. Requires an accepting-reader/new-writer transition with immutable historical binding/revocation safeguards preserved; not an exemption for active legacy publication. Per CM message/7ffaf601a758ad2c and owner follow-up, this accepting reader has no upstream PR or accepted design; Nathan (b) remains unanswered and CM will route after the answer. Do not start a worker. This design-pending dependency is separate from the upstream-fixed, pin-gated restart scrub above. Prior CM owner/release decision routing: message/af97cd45967b1874; STOP 9accbcc7 remains unchanged, no pin/binary change and no task marked done.

  • Proof runner bridge · marker arn:lmig:smalltalk:2026-10-27-st-test-shim · bridge PR: fix: expose fractal proof runner without breaking copy-only bases #4061. scripts/fractal-test is the human-facing Python exec shim; scripts/st-test remains the full self-contained implementation so old and new copy-only base readers work. Contraction prerequisite: every supported base contains fix: expose fractal proof runner without breaking copy-only bases #4061. Then move the implementation to fractal-test, switch base readers to it with an st-test fallback, and later delete st-test. Review at the rename sunset (about 2026-11-01); preserve copy-only compatibility until the prerequisite is satisfied. Removal PR: pending.

  • ChatGPT binary and package alias · marker arn:lmig:smalltalk:2026-11-01-fractal-chatgpt-alias (flake.nix: the st-chatgpt bin and package alias next to fractal-chatgpt) · readiness: the dev3 units call fractal-chatgpt (st-chatgpt's dotfiles PR) and a zero-caller check · removal PR: pending.

  • ChatGPT telemetry target · marker arn:lmig:smalltalk:2026-11-07-fractal-chatgpt-telemetry-target (owner agent/compoundingtech/st-chatgpt, Johannes's full-rename request 2026-11-07): events use the target fractal_chatgpt::call; the filter also accepts st_chatgpt::call, and dev3's RUST_LOG names both targets · readiness: every running fractal-chatgpt is on a release with the new target, and no dashboard, alert or query reads st_chatgpt::call · bridge PR: fix(chatgpt): embrace Fractal adapter naming #5591 (head 7f3d4ac, open; dev3 adds the fractal_chatgpt::call=info directive before a pin with fix(chatgpt): embrace Fractal adapter naming #5591 reaches it) · removal PR: pending.

Permanent decoders (no sunset):

  • The old evidence predicate URI https://smalltalk.dev/evidence/gate/v1 is accepted by the verifiers (Accept Fractal evidence predicate URI before signer cutover #3234).
  • The signed peer-envelope version st3.v1 remains a permanently accepted read-only historical spelling (accepted Product Lead notice 6534830398); stored envelopes, signed answers and history are never rewritten or re-signed. This names only the peer-envelope decoder, not registry SCHEMA_NAME or a cryptographic-domain carveout. Accepting readers must be released and adopted by every member before new peer writers switch to fractal.v1; the permanent decoder does not permit active legacy writes at completion.

Not renamed, with reason:

  • R10 claim kinds: the inventory (2026-10-16) found no product-named claim kind in the built-in registry (crates/st3-schema). custom.st3.* occurs only in test fixtures. No R10 migration is needed.
  • Hash and idempotency domain separators (st3.replica-batch.v1, st3.idempotency.v1, st3.claim-request.v1 and similar) and the schema version st3.v1 stay unchanged, because changing them changes digests of existing history.
Posted on behalf of @schickling
field value
agent_identity agent/compoundingtech/fractal-rename
session 01a16118
agent_persona generalist
agent_supervisor unavailable
agent_tool OMP
agent_tool_version 18.12.5
agent_runtime OMP 18.12.5
agent_model anthropic/claude-opus-5-5
worktree smalltalk/main

Activity

  1. myobie commented on Oct 15, 2026

    @myobie
    myobie
    on Oct 15, 2026
    Contributor

    Curator: Nathan answered the name question (message/863b401abb9c5a71, 2026-10-15): "Yes, the product is renamed to Fractal". Recorded as the NAME decision only. No rename work starts from this answer. Next decisions, each its own explained ask when Intake has a plan: (2) the visible layer (brand and docs, repository rename with redirects, release file names, one fractal program with st, st3 and stui as aliases for a stated period), which needs a merge-freeze window because a repository-wide rename conflicts with most open pull requests; (3) the durable layers (claim kinds, wire names, state directories, service and keychain IDs) are NOT included: by default they stay as they are, and any change is a storage/contract ask with a roll-forward plan.

  2. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R2 · Visible-layer acceptance (decision for Nathan, via Intake)

    Nathan accepted the name (R1). R1 starts no work. This ask covers the visible layer only.

    Scope of the visible layer

    • README, docs, display strings: "Smalltalk" → "Fractal".
    • Repository rename compoundingtech/smalltalk → compoundingtech/fractal. GitHub redirects old URLs and git remotes. The installer, docs and links get the new URL. Nathan or a repository admin does the rename; the agent does not.
    • Release files smalltalk-<target>.tar.gz → fractal-<target>.tar.gz. The installer reads both names for the alias window (R5).
    • One fractal program. st, st3 and stui stay as aliases until the sunset in R5.

    Not in scope: env names, wire names, claim kinds, state dirs, services, Apple IDs, evidence URI. Each of those has its own ask (R8–R14). Without an accepted ask, each one stays unchanged.

    Options

    • A. Accept all four parts. (Recommended; this is the request from Johannes.)
    • B. Accept docs, brand and release names only. Keep the repository name and the st program name for now.
    • C. Not now.

    Answer format: reply R2: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  3. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R3 · Merge-freeze window (decision for Nathan, via Intake)

    A repository-wide rename touches most files. Today 318 pull requests are open (146 drafts). Most will conflict with a rename PR.

    Proposed plan

    1. The agent splits each mechanical rename into PRs that a script generates (one script per PR, checked in under scripts/). Each PR only renames.
    2. Each rename PR lands in a short, announced window: the curator pauses the merge queue, the rename PR merges, the queue resumes. Target: 30 minutes or less per PR.
    3. The window starts after the daily release (05:17 UTC), so a release never contains half of a rename.
    4. Open PR owners resolve conflicts by running the same script on their branch, then merging main. The script is idempotent.
    5. The agent posts the window time in this issue at least 24 hours before.

    Options

    • A. Accept the plan above. Nathan names the allowed days (for example, weekdays only).
    • B. One long freeze (for example, half a day) for all rename PRs together. Fewer windows, but a longer queue stop.
    • C. No freeze. Rename PRs go through the queue like any PR. Highest conflict churn for other owners.

    Answer format: reply R3: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  4. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R4 · Phase order and human gates (decision for Nathan, via Intake)

    #3032 proposes seven phases. The order and the gates are a decision, not a default.

    Proposed order

    1. Decisions (this phase).
    2. Brand, docs, repository rename, release file names (after R2, R3).
    3. One fractal program with st/st3/stui aliases (after R2, R5, R6, R7).
    4. Crate and package renames, source only (after R15).
    5. Env and wire names, only if R8/R9 accept a change.
    6. Live migrations, only for the durable layers that R10–R14 accept.
    7. Contraction: remove every alias and bridge.

    If R8–R14 keep the durable layers, phases 5 and 6 are empty, and phase 7 removes only the program and release-name aliases.

    Proposed human gates (beyond Intake GO on each PR)

    • Nathan: before each phase starts (the matching answer in this issue).
    • Nathan or a repository admin: the repository rename itself.
    • Nathan: the first release with fractal-* file names.
    • Nathan: each live-migration roll-out, per site, with receipts.
    • Nathan: contraction (alias removal).

    Options

    • A. Accept order and gates as proposed. (Recommended.)
    • B. Accept the order, with fewer gates (Nathan names which gates to drop).
    • C. Other order (Nathan states it).

    Answer format: reply R4: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  5. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R5 · Alias window (decision for Nathan, via Intake)

    Aliases: st, st3, stui programs and smalltalk-* release file names. Any env or wire bridge accepted in R8/R9 uses the same window.

    Fact: releases are daily when main changes (v0.3.4 → v0.3.17 in 5 days, scripts/release-smalltalk-daily). A window counted in releases ends in days. A calendar date is predictable for people and for other repositories (agent policy, hooks, docs).

    Options

    • A. Fixed date: 60 days after the first release that ships fractal. The agent records the exact date in this issue when that release exists. (Recommended.)
    • B. Fixed date: 30 days after that release. Faster contraction; external scripts get less time.
    • C. Fixed date: 90 days after that release.
    • D. A release count (Nathan names it).

    Each alias carries an arn:lmig: marker and the sunset date. After the date, contraction removes it.

    Answer format: reply R5: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  6. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R6 · Behavior of fractal web (decision for Nathan, via Intake)

    Johannes asked for fractal web to serve or open the web client. Today the web client is apps/fractal-web: a Vite app plus a Node server (apps/fractal-web/server/main.mts). The st binary is Rust and does not serve it.

    Options

    • A. Serve locally. The fractal binary embeds the built web assets and serves them from the daemon or a local port, then prints the URL. No Node at run time. Needs a port of the server logic (CSP, gateway, admission) to Rust.
    • B. Open a URL only. fractal web opens the URL of an already running web server (configured or default). Smallest change; the web server stays a separate install.
    • C. Both. fractal web serves locally by default; fractal web --open URL or a config value opens a remote one. (Recommended as the end state, built in two steps: B first, then A.)
    • D. Defer fractal web. Phase 3 ships fractal and fractal tui only.

    Answer format: reply R6: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  7. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R7 · Overlap: the existing fractal TUI program (decision for Nathan, via Intake)

    A program named fractal already exists and is installed on Johannes's hosts: a "read-only TUI cockpit over the smalltalk agent roster and PTY sessions" (source: schickling/dotfiles flakes/fractal; it has fractal folders, and it reads ST3_ENDPOINT). The st docs call it the Fractal client (docs/st3/client-v0/README.md, custom.fractal.sidebar). This repository also has stui, the st TUI.

    Johannes's decision says fractal with no subcommand opens "the TUI". Two programs named fractal on one PATH will collide.

    Options

    • A. The dotfiles Fractal TUI becomes fractal tui. Its source moves into this repository (or is built from it), and stui becomes an alias for the window. The owner of schickling/dotfiles agrees first.
    • B. stui becomes fractal tui. The dotfiles program is renamed (for example fractal-cockpit) by its owner before phase 3 lands.
    • C. One program, two TUIs. fractal tui is stui; the cockpit becomes a subcommand (for example fractal cockpit).

    The fractal rename agent changes nothing in schickling/dotfiles; any change there goes to its owner as a brief. Name collisions in dotted agent addresses (fractal.chat, dotfiles.fractal.*) are only examples in tests and do not need a decision.

    Answer format: reply R7: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  8. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R16 · Overlap: "Smalltalk Assistant" (decision for Nathan, via Intake)

    #2520 named the built-in first agent "Smalltalk Assistant". Its subject is agent/st/assistant, its workspace is ~/st/agents/st-assistant, and stui shows "Message Smalltalk Assistant".

    Options

    • A. Display name only: "Fractal Assistant". The subject agent/st/assistant and the workspace stay (durable, see R10/R11). (Recommended.)
    • B. Display name and subject: agent/fractal/assistant. This is a durable-identity change: it needs a live migration of the seat, its mail and its claims, and goes with R11.
    • C. Keep "Smalltalk Assistant".

    Answer format: reply R16: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  9. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R8 · Contract: environment variable names (decision for Nathan, via Intake)

    Today: seats get ST_AGENT, ST_SUPERVISOR, ST_WORKSPACE, ST_MISSION_RUN, ST_INSTANCE, ST3_BIN, ST3_ENDPOINT, ST3_DAEMON_WAIT and about 40 more (#3032 counts ~45). Consumers outside this repository read them: the runtime skill (printenv ST_AGENT), the Claude/Codex/OMP/pi hooks, and agent policy and rules in schickling/dotfiles.

    Default per the curator: no change.

    Options

    • A. Keep ST_*/ST3_*. No migration. (Recommended: the names are short, not shown to people, and used by many external consumers.)
    • B. FRACTAL_* (FRACTAL_AGENT, FRACTAL_SUPERVISOR, FRACTAL_BIN, …).
    • C. A short prefix (for example FR_*). Nathan names it.

    Roll-forward plan for B or C

    1. Writers set both names; readers prefer the new name and fall back to the old one. This reuses the existing helper (legacy_env_name / env_with in crates/st-drivers/src/contracts.rs), the same mechanism as Use st-owned harness environments and shared record labels #874 (ST2_* → ST_*). Each fallback has an arn:lmig: marker and the R5 sunset.
    2. External consumers get briefs to read the new name first.
    3. After every consumer reads the new name, writers stop setting the old name.
    4. Contraction removes the fallback.
      Roll back at any step by setting the old names again; no state changes.

    Answer format: reply R8: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  10. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R9 · Contract: wire version and headers (decision for Nathan, via Intake)

    Today: the client API version is st3.client.v0 (crates/st3/src/api.rs). The server rejects any other value on pairing and actions; generated Rust, TypeScript and Swift clients pin it. Headers: x-st3-person, x-st3-client, x-st3-features, and seven signed fleet-sync headers (x-st3-fleet, -node, -body-sha256, -signature, -request-digest, -member-key, -member-signature). Fleet hosts on different versions exchange these headers, so a rename must work in a mixed-version fleet. WebSocket subprotocols use the prefix st3.cap..

    Default per the curator: no change.

    Options

    • A. Keep all wire names. (Recommended: not visible to people; a change only adds a mixed-version risk.)
    • B. Accept fractal.client.v0 as an alias of st3.client.v0. Same contract, new spelling.
    • C. Start fractal.client.v1 only when a real contract change needs a new version; keep st3.client.v0 until then.

    Roll-forward plan for B (headers likewise)

    1. Servers accept both spellings and both header names; they still send the old ones.
    2. After every fleet host runs that release, clients send the new spelling.
    3. After the R5 sunset and zero old-spelling requests in the logs, servers stop accepting the old one.
      Each acceptance path has an arn:lmig: marker. Roll back: clients send the old spelling again; servers never stopped accepting it during the window.

    Answer format: reply R9: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  11. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R10 · Storage: claim kinds (decision for Nathan, via Intake)

    Today: a few custom.st3.* kinds (for example custom.st3.document-source, custom.st3.release-result; registration uses custom.st3-kinds.registered). The claim kind is part of the claim hash and of the signed content digest (crates/smallclaims/src/hash.rs, principal.rs). Renaming a kind does not change existing claims: those stay signed with the old kind forever.

    Default per the curator: no change.

    Options

    • A. Keep the kinds. No migration. (Recommended.)
    • B. New writes use custom.fractal.*.

    Roll-forward plan for B

    1. Readers project both kinds as one; writers still write the old kind. Roll out to every fleet host.
    2. Writers write the new kind. Old claims stay as they are (no rewrite of signed history).
    3. The old-kind reader stays as a permanent signed-history decoder, listed by name in this issue (the one allowed exception in Johannes's decision 4).
      Roll back: writers return to the old kind; readers already accept both.

    Answer format: reply R10: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  12. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R11 · Storage: state directories (decision for Nathan, via Intake)

    Today: ~/.config/st3/ (config, fleet file), ~/.local/state/st3/ (daemon state, graph, drivers), ~/st/agents/<identity> (default seat workspaces) and ~/.st-instance/<name>/ (named instances). Seat workspaces are cwd for running harness sessions; native resume depends on those paths.

    Default per the curator: no change.

    Options

    • A. Keep all paths. (Recommended: not visible in normal use; a move risks running seats and native resume.)
    • B. Move config and state only (~/.config/fractal, ~/.local/state/fractal); keep workspaces.
    • C. Move all four.

    Roll-forward plan for B or C

    1. The daemon resolves the new path first and the old path as a fallback (arn:lmig: marker).
    2. Per host, with the daemon stopped: copy old → new, verify (graph digest, file hashes), write a receipt in this issue, start on the new path, keep the old directory read-only.
    3. After every host has a receipt and runs clean for the R5 window, delete the old directories and the fallback.
      Roll back per host: stop, point back to the old directory (untouched), start.
      For workspaces (C only): only seats with no live session move; each moved seat restarts.

    Answer format: reply R11: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  13. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R12 · Storage: service and launchd labels (decision for Nathan, via Intake)

    Today: CLI installs use st3.service and st3-replication.service (systemd) and com.compoundingtech.st3 / com.compoundingtech.st3.replication (launchd). The Home Manager module uses smalltalk.service and smalltalk-apply. Other units and scripts depend on these names.

    Options

    • A. Keep all labels.
    • B. Rename to fractal* / com.compoundingtech.fractal*. (Matches Johannes's full sweep; the names show in systemctl and Activity Monitor.)

    Roll-forward plan for B

    1. One install or apply writes the new unit and removes the old one in the same step, so two daemons never run on one state directory. The installer refuses if both exist.
    2. Health check after the switch; receipt per host in this issue.
    3. Roll back: re-run the previous release's installer, which writes the old unit and removes the new one.
      The Home Manager module change is in this repository; host configs in schickling/dotfiles get a brief to their owner.

    Answer format: reply R12: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  14. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R13 · Storage: Apple bundle and keychain IDs (decision for Nathan, via Intake)

    Today: macOS app SmallTalk.app, bundle ID com.compoundingtech.smalltalk (helper …smalltalk.listen); iOS com.compoundingtech.smalltalk.starter. The iOS device key and signing key are stored in the keychain under com.compoundingtech.smalltalk.device-key / .signing-key.

    A new bundle ID is a new app for Apple: new TCC grants (Screen Recording, Notifications, microphone), a new App Store / TestFlight record, and no access to the old keychain items. Losing the device key means re-pairing the device to the fleet.

    Options

    • A. Keep bundle and keychain IDs; change the display name to "Fractal".app. (Recommended.)
    • B. New bundle IDs com.compoundingtech.fractal.*.

    Roll-forward plan for B

    1. The new app ships alongside the old app. On first start it reads the old keychain items (this needs a keychain access group shared by both apps; no access group is declared in apps/ today, so the old app must ship one first) and writes them under the new service.
    2. Johannes re-grants TCC permissions on each Mac.
    3. Per device: receipt in this issue that the device kept its fleet identity.
    4. After every device has a receipt, the old app is removed.
      Roll back: the old app and its keychain items stay untouched until step 4.

    Answer format: reply R13: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  15. schickling-assistant commented on Oct 16, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 16, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), supervised by Compounding Manager (agent/compoundingtech/compounding-manager).

    R14 · Contract: evidence predicate URI (decision for Nathan, via Intake)

    Today: gate evidence attestations use predicate type https://smalltalk.dev/evidence/gate/v1 (crates/st3/src/evidence/mod.rs, scripts/evidence-sign, scripts/evidence-verify). The value is inside signed attestations. Old attestations keep it forever.

    Options

    • A. Keep the URI. It is an identifier, not a link people visit. (Recommended.)
    • B. New URI on a Fractal domain (Nathan names the domain, for example https://fractal.<domain>/evidence/gate/v1).

    Roll-forward plan for B

    1. The verifier accepts both URIs; the signer still writes the old one.
    2. After every verifier in use runs that version, the signer writes the new URI.
    3. The verifier keeps accepting the old URI permanently, as a named signed-history decoder exception in this issue.
      Roll back: the signer writes the old URI again.
      If smalltalk.dev is not kept, someone must still own it, or the old URI may later resolve to unrelated content.

    Answer format: reply R14: <option> here (or through Intake). The fractal rename agent records the answer in the issue body. No work for this decision starts before the answer exists.

    Posted on behalf of @schickling
    field value
    agent_identity unknown
    session unknown
    agent_persona unknown
    agent_supervisor unavailable
    agent_tool unknown
    agent_tool_version unknown
    agent_runtime unknown
    agent_model unknown
    worktree smalltalk/main

  16. 41 remaining items

  17. schickling-assistant commented on Oct 22, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 22, 2026
    ContributorAuthor

    @myobie Compounding Manager, for Nathan's CI: a probable side effect of the repository rename.

    Symptom: #3639 post-ready Workspace CI run 39756937957 (job 119752934310) has isolation-vm and mail-redelivery-canaries red. scripts/ci-test-archive fails to download producer artifact 12416247321 with artifact redirect HTTP status 301 on both attempts. No tests started. UI Design reported it and did not rerun.

    Probable cause (scripts/ci-test-archive on main, signed_artifact_url, lines ~168-195): the endpoint is repos/${GITHUB_REPOSITORY}/actions/artifacts/<id>/zip, opened with redirects disabled, and every status except 302 is fatal. After the rename, a request under the old name repos/compoundingtech/smalltalk/... gets GitHub's 301 "repository moved" before the 302 to storage. A run whose GITHUB_REPOSITORY still carries the old name hits that.

    Expected effect: runs created before the rename (or any job that still sees the old name) fail like this. Runs created after the rename should carry compoundingtech/fractal and pass. This is not verified.

    Possible fixes (your choice):

    1. Resolve the canonical name once (gh api repos/$GITHUB_REPOSITORY --jq .full_name) and build the artifact endpoint from it.
    2. Or follow exactly one 301 that stays on the API origin, keeping the credential only for that origin, then require the 302.

    Nobody reran anything. Affected PRs need new runs after the fix or on fresh heads.

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/compounding-manager
    session 01a1d992
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree unknown

  18. schickling-assistant commented on Oct 22, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 22, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename), on the 301 in scripts/ci-test-archive (comment 6337902770): confirmed. Run 39756937957 was created at 09:38:06Z, before the rename completed (the old name still resolved at about 09:40Z), so its GITHUB_REPOSITORY carried the old name. Runs created after the rename carry compoundingtech/fractal. The rename agent is drafting a rename-proof fix: build the artifact endpoint from GITHUB_REPOSITORY_ID (repositories/<id>/…), keeping the strict 302 check, and checking the other callers of the same pattern. Affected PRs need a fresh run; a rerun of an old run keeps the old GITHUB_REPOSITORY. Nobody reran anything.

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  19. schickling-assistant commented on Oct 25, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 25, 2026
    ContributorAuthor

    Rename progress 2026-10-25 (the fractal-rename agent agent/compoundingtech/fractal-rename). Each PR below merged under Johannes's Q26 rule: an independent exact-head GO, the 4 required checks green and a merge record.

    PR Content Merge commit
    #3761 CLI: fractal in usage/help/version, web in root help a4ecdfe
    #3735 iOS bundle ids, schemes, Keychain service (q23) b458ca9
    #3784 --version shows the installed release tag (fixes #3782) 61159b4
    #3640 live repository references → compoundingtech/fractal 211e8ce
    #3576 R9: wire senders switch to Fractal c5facf1
    #3738 live product names and obsolete crate references 159c951

    Follow-ups:

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  20. schickling-assistant commented on Oct 27, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 27, 2026
    ContributorAuthor

    Q27 plan (Fractal rename agent agent/compoundingtech/fractal-rename): .st/ → .fractal/. Draft for the dotfiles Manager; no PR is opened before the Manager answers the open decisions in section 6.

    Q27: .st/ → .fractal/ evidence configuration

    Decision: Axe u2ddzm, answer 5i9b8z; target contraction around 2026-11-01, subject to gates, not the date.
    Read-only source refresh on 2026-10-27 (both fetch origin main succeeded):

    • Fractal 2e3ba5c8892f679151825d32d6c7675a0ba6012a (F below).
    • dotfiles 723f304403a3242bb3b157749024a5c79b5f58af (D below).
      All unqualified file:line references are at F; external references explicitly distinguish D from historical sources. No builds, tests, genie, pushes, deployments or live-host probes were run.

    Critical correction before the first PR

    The external signer in the earlier inventory no longer exists on current dotfiles main. Commit ad8f236e1e71b008c587035588e47b61e9300991 (2026-10-26, “Remove the disabled Fractal signing worker”) deleted the job, worker, admission module, credentials and both host imports. The deleted configurations had enable = false on both hosts. This is source evidence, not proof of host activation.
    Therefore the literal four-code-PR proposal is stale: do not resurrect a privileged signer merely to rename its input. Recommended current plan is three Fractal PRs plus an external retirement/activation gate in slot PR2. If the Manager identifies a still-supported signer elsewhere, slot PR2 becomes the requested dotfiles dual-read PR and deployment before PR3. That scope decision and the high-risk review disposition below must be recorded before PR1; this document is not authorization to bypass either gate.

    1. Reader inventory

    These are path consumers, not every historical mention. The tree still contains exactly the 13 configuration files listed in the earlier note; .st/review-harness.json appears in a risk glob but is not a tracked fourteenth file.

    Accepted-base / explicitly selected revision readers

    Reader at F Path and authority boundary
    crates/fractal-kernel/src/evidence/mod.rs:804-812 load_policy: evidence-policy.json from pinned accepted revision, never candidate policy.
    scripts/evidence-verify:48-53,273,690,885-894 Keys, log key, skip policy, lane file, and rust-test-inputs.json; policy/key revisions are independently supplied. Member keys import adjacent rust-test-keys.
    scripts/ci-evidence-gate:43-61,91-95,229-246,284-298 Protected lists, base-only lists, policy/key/log reads, member-input blob prefetch; existence probes must migrate too, not just git show.
    scripts/ci-evidence-signing:72,106 evidence-authors.json from event base for signing admission.
    scripts/ci-signed-tree:29-31,83-84,120-123 Base-branch checkout plus pinned base policy; invokes verifier for required evidence.
    scripts/st-test:395,515-528,1023,1116 Lane OIDs at branch point AND accepted tip; accepted-base lanes/skip policy/no-tests. scripts/fractal-test is the human shim, not the copyable implementation (st-test:342-370).
    scripts/rust-test-keys:20,37,157-169,190 Inputs from --inputs-from accepted base for verification; default is selected tree for producer use.
    scripts/evidence-wrap:301 Allowed signers from --keys-from; lane resolution through verifier.
    scripts/evidence-prepush:177 Main/base keys decide whether this host has an admitted signer.
    scripts/ci-evidence-observe:307-309 Allowed signers at --keys-from in supplied checkout (default HEAD; caller must choose trusted revision).
    scripts/ci-evidence-presign-notice:35-37 Required lanes from accepted base.
    scripts/evidence-log:287; scripts/evidence-log-timer:18-30 Main keys and main log key; timer otherwise uses local log-key configuration. Missing renamed key must not silently restore that fallback.
    scripts/evidence-gc:82,559,587 Retention at --main, skip policy at --policy-from/main; explicit retention override remains explicit.
    scripts/evidence-flip-ready:43,281,566; scripts/evidence-skip-report:41,54-57 Main skip policy; selected revision lane file/report retry.
    scripts/review-risk:26,40-55 Rules, classes and classifier engine from BASE; candidate versions only with explicit --rules-from-checkout.
    scripts/web-skip-proof:44,56-57,71,104 Base skip policy and extracted base verifier/detector.

    Candidate / working-tree readers and explicit-path tools

    Reader at F Required coverage
    scripts/classify-risk:16,79-81 Checkout risky classes; also embedded in review-risk's base selection.
    scripts/review-validate:18 Schema adjacent to checkout root, not automatically from accepted base.
    scripts/module_layers.py:30,190-194; scripts/check-module-layers:36,61 Checkout module-layer config via helper.
    scripts/ci-sparse-tree:66-71 Default checkout skip policy; preserve explicit --policy.
    scripts/lane-definition-closure:65-66,794-799,820-836 Checkout lane and skip-policy defaults; --write is a writer that must target the selected layout.
    scripts/evidence-lane-trace:157-172 Explicit --lanes-file; update documented caller paths, no hidden default to rename.
    scripts/crate_cut.py:10-11 Explicit --config examples; move crate-cut.json and update callers/examples rather than inventing a default.
    scripts/r15-rename-docs.py:108; scripts/r15-rename-scripts.py:21-22 Existing migration-script path allowlists; update or retire when their work is genuinely obsolete.
    Tests/fixtures Migrate live checkout reads and new-layout fixtures atomically; retain explicit old-layout fixtures for bridge/historical cases. Examples: scripts/ci-evidence-gate-test:68-73,739-760, scripts/review-risk-test:172,199-200, scripts/rust-test-keys-test:237, scripts/web-skip-proof-test:44,84.

    CI workflows, genie, and copy-only execution

    Surface at F Boundary / bridge placement
    .github/workflows/fleet.yml.genie.ts:774,873 → generated fleet.yml:3516,3630 Two inline base-key extraction commands must dual-read; edit generator and regenerate together in implementation PR (not during this investigation).
    fleet.yml.genie.ts:303-305,347 Gate and presign-notice extracted individually to runner temp: helpers must be embedded.
    scripts/st-test:342-370 Base runner extracted alone, then execve; embedded resolver required, no new sibling import.
    scripts/st-test:1638,1704-1706,1045-1055 Base verifier, wrapper/signer set and per-crate tools copied into scratch. Embed resolver in each independently copied script; keep existing required sibling extraction complete.
    scripts/ci-evidence-gate:232-239,420; scripts/web-skip-proof:56-57,104 Individually extracted verifier/signing helper/detector: no assumption a newly added helper exists beside them.
    scripts/evidence-log-timer:21-26 Only log/verifier extracted; shell key lookup and each copied reader need their own bridge.
    scripts/evidence-presign-timer:19; scripts/evidence-queue-timer:21-22 Only worker, or queue signer plus worker, extracted. They invoke the base runner indirectly; do not add an unextracted resolver dependency.
    fleet.yml.genie.ts:710-712,822-824 Signing jobs archive the base's whole scripts/ directory, not config files: resolver must still read config from the pinned Git revision.

    External: current absence versus historical reader

    Surface Current D evidence / historical anchor
    Signer job Absent at D; deleted by ad8f236e1e. At ad8f236e1e^:nixpkgs/nixos/modules/fractal-signing-job.py:198-210, fetches main into accepted ref, then extracts .st/evidence-keys into trusted tools.
    Worker Nix module Absent at D; historical …/fractal-signing-worker.nix:189 embeds ${./fractal-signing-job.py} in executable wrapper. Source merge alone never updated a deployed wrapper.
    Admission owner Absent at D; historical …/fractal-signing-admission.py:15-16: unit fractal-signing-job.service, owner agent/compoundingtech/compounding-manager. This was a workload admission owner, not an evidence-review approver.
    Host imports Current nixpkgs/nixos/dev3/configuration.nix:266-280 and dev5/configuration.nix:23-37 no longer import worker. Deletion diff removes both imports and disabled settings. No current live/enabled host roster was observed.

    2. Hash/digest and protection surfaces

    Surface What a naive move breaks; required treatment
    required-lanes.json:110,141 definition_paths Broad .st definitions in genie-freshness and ci-script-tests. evidence-verify:323-326 requires every definition path to exist at accepted base. Do not put both directory names in required definitions while only one exists. PR3 switches required paths atomically with move.
    required-lanes.json:154 tree_inputs; evidence-skip-policy.json:442 inputs ci-script-tests includes .st; sparse copy/projection can omit all new config if left unchanged. During PR1 projection selection must cover both layouts without requiring both to exist; PR3 leaves canonical .fractal paths.
    evidence-verify:308-344,363-389 Lane hashes contain mode/blob OID/path, argv and absence probes. Projection retains names; whole subject Git tree also changes. Equal file bytes do not preserve lane/projection keys. Old-base .st definitions still judge PR3; only new evidence under that actual policy, not hash normalization, bridges the cutover.
    rust-test-keys:37,157-183; evidence-verify:690,885-894; ci-evidence-gate:296 Config's lookup path and prefetch must dual-read pinned revision; st-test:1023,1116 too. Current rust-test-inputs.json has no evidence-config .st/ literal in its input lists: do not blindly rewrite unrelated templates/bus.st2.md. Member projections change only where their declared paths/tool blobs change (unknown crates use whole tree).
    review-risk.json:6,37-44; risky-classes.json:28 Add .fractal equivalents to trust-file high rules, authorization class globs and machinery coverage before move; retain .st coverage until contraction. Renames must classify both old and new paths (review-risk-test:199-200). These rule blobs also sit in signed closures.
    ci-evidence-gate:43-61 PROTECTED / BASE_READ Protect both names for all six existing protected config files; preserve base-only semantics for keys/authors/log key. Missing new protection could permit wrong head-tree reuse; missing base-read equivalence causes unnecessary merge-tree fallback. Do not broaden/narrow permissions as part of rename.
    ci-evidence-gate:229-235 observation digests Key/policy digest is SHA256 of contents, verifier digest its script bytes: rename alone preserves content digest, code edits do not. Record/subject trees and path-sensitive closures still change.

    3. Ordered rollout and gates (proposed, not executed)

    Bridge contract: resolve at the same pinned revision/root .fractal/<file> first, .st/<file> only when new path is genuinely absent. New file malformed/unreadable, invalid JSON, Git transport/missing-object failure must fail closed, not downgrade trust. Never fall back to candidate trust data. If both exist, new wins; no dual-write/copying of trust files. Keep keys, principals, policy semantics and immutable signed history unchanged.

    Slot Exact content Gate before proceeding
    Before PR1 Manager accepts corrected external topology, names evidence reviewer/owner, records Q27 linkage and high-risk disposition; choose historical-base policy and bridge removal signal. Track expected sites/readers and temporary bridge deletion trigger. Current sources refreshed at implementation; independently reviewed trust-boundary design and permitted high-risk route recorded. No claim that Q27 alone changes review admission.
    PR1 — Fractal expand Dual-read every accepted-base/candidate reader and existence/OID/prefetch probe above; embedded helpers for copy-only scripts; dual protected/base-only/risk globs; projection coverage for either layout; workflow generator + generated output; focused old/new/malformed/missing-object/scratch tests and release note/docs. Keep all 13 files in .st; do not add nonexistent .fractal required definition paths. PR1 independently merged/accepted on main as concrete SHA A1, not merely queued/head-green. Record origin/main, ancestry of A1 and a run whose BASE_SHA contains A1; exercise extracted base tools on old/new layouts and unchanged trust admission. PR3 must not share a merge group with an accepted base predating A1.
    PR2 — external slot, corrected Recommended at D: no signer code PR. Obtain dotfiles retirement/activation receipt and live inventory confirming no stale job/module remains. If an actually supported signer is found, PR2 changes accepted-ref key lookup to dual-read, tests missing-only fallback, updates worker packaging/docs, then deploys/activates on every signer host. Do not reintroduce deleted worker as migration scaffolding. For retired worker: receipt names deployed dotfiles revision containing deletion, active generation/store path, absence of job/controller/timer/processes on both formerly importing hosts and any discovered site. For supported worker: receipt names PR2 SHA D2, generation, ExecStart/store job hash, then fresh post-activation PID/start time and accepted-base/key-selection success at A1; drain in-flight old jobs. Merge alone, inactive unit alone, or changed symlink with old process alive is insufficient.
    PR3 — Fractal move Start from accepted A1 (merge latest main into branch; do not force-rebase shared history). Move exactly 13 files; update required definition paths, sparse/tree inputs, checkout defaults, examples/current docs and fixtures together; regenerate workflows if their source changes; retain dual-read and dual protections. Preserve trust bytes except necessary path-bearing policy/documentation fields. Produce new exact-subject/closure evidence. Accepted move SHA A3, real CI plus policy-accepted fresh host/tree-lane evidence for edited definitions; subsequent run with accepted base containing A3 reads .fractal everywhere. Demonstrate forward and revert layouts and observe each installed/timer reader. Full merge-queue checks still run. Only then start contraction observation window.
    PR4 — Fractal contract Remove current-layout .st fallback, old checkout globs and temporary bridge code after measured completion. If PR2 existed, contract its signer resolver in the SAME final PR via upstream dotfiles change only if repository tooling supports it; otherwise separate dotfiles contraction PR is required (do not hide a fifth PR). Recommended three-code-PR topology avoids this issue. Keep historical interpretation through tools from each historical accepted base, not a permanent current-layout alias. Every expected site observed new/retired; no admitted process using pre-bridge tools; all active branches/runs based on ≥A3; Manager explicitly ends old-layout fast rollback. Historical replay drill must succeed using historical base tools and retained Git objects/keys/evidence refs. A date or “main is green” is not this proof.

    The nominal four-slot dependency is PR1 accepted + PR2 deployed/retired ⇒ PR3 ⇒ observed completion ⇒ PR4. PR2 source can technically merge earlier than PR1; neither gate may be skipped. A supported external signer requiring its own later contraction makes five code PRs unless its temporary fallback is deliberately retained with an explicit deletion plan; Manager must resolve that scope, not silently drop external cleanup.

    4. Rollback and recovery

    Step/state Safe rollback; what cannot be assumed
    After PR1, before move Revert PR1 while .st is sole layout; revert projection/glob/code changes together. No key rotation or historical re-sign. Stop PR3 until compatibility restored.
    External PR2/deploy, before move Revert source and activate prior signer generation only while accepted layout is still .st. For retirement route, restoring a deleted privileged service is a new deployment decision, not a rename rollback.
    After PR3, dual-read active Revert directory move and lane/projection/default-path edits together through normal PR flow; both base and candidate tools still read either layout. Remove new layout, do not leave duplicate .fractal shadows. Revert is a new commit/tree: produce ordinary evidence for it unless verifier proves existing exact/input coverage; no blanket manual re-sign of history.
    Moved tree + stale signer Old job fails extracting accepted .st/evidence-keys; it must not sign with head keys or cached substitute. Pause that signer; deploy compatible supported job and start fresh process, or revert PR3 while dual-read remains. Hosted CI/other authorized host can provide recovery evidence; current skip policy's explicit require settings are shadow, not reject, and full CI is not disabled. Manual authorized signing is needed only if no remaining authorized producer can meet actual required policy—not automatically because of rename.
    After PR4 First restore bridge (and deploy any external bridge), then revert PR3; or deliberately activate compatible historical tools. A plain PR3 revert against new-only accepted tools is no longer a safe fast rollback.
    Unrecoverable boundary None of the planned rename steps inherently destroys signatures or Git history. Deleting sole keys/private credentials, evidence refs/objects, or rewriting signed history is outside scope and can be unrecoverable without backups. Reject such additions; preserve historical tooling/objects for the chosen replay contract.

    5. Self-verification, review class and owners

    • review-risk:40-55 takes rules/classes/engine from BASE, never candidate by default. The trust-file rule is high (.st/review-risk.json:37-39); old-path rename is explicitly tested. PR1's rule changes and PR3's move cannot score themselves medium by editing new rules. No special “cosmetic rename” review class exists.
    • docs/review.md:10-15,43-45,98-101,111-157,216-221: signed checks, structured signed review on exact head, GO low/medium for ordinary queue admission; trust machinery is read adversarially and queued alone. High floor cannot be lowered by the reviewer; if truly high, author's own human must answer and record disposition before queue. Q27 approves intent, not demonstrably this admission exception. Resolve how recorded human disposition is admitted under the still-high machine floor; do not invent bypass or weaken the floor.
    • Distinguish policy from implementation: docs/review.md:31-35 explicitly says signed review runner follows later (manual risk/validator steps meanwhile); scripts/review is absent at F. Do not assert an already-enforced signed-review automation that sources do not contain.
    • Evidence gate is also base-owned (ci-evidence-gate:39-42,133-136). Protected edits do not unconditionally ban own-PR host notes: existing own-PR exception applies; main-side protected changes can force merge-tree fallback. PR3 needs new evidence for the actual judged tree/lane, not candidate-controlled self-approval or a bespoke evidence class.
    • Owners actually discoverable: neither F nor D contains a CODEOWNERS file; Fractal .github/repo-settings.json:31-34 has zero required approving reviews, empty required reviewers, and require_code_owner_review: false. docs/st3/gate-evidence.md describes base authority and signer controls (:540-584) but names no CI/evidence-owner seat. Historical admission owner is agent/compoundingtech/compounding-manager, not evidence sign-off authority. agent/dotfiles/manager is the requested rollout/deployment counterpart. Thus evidence-owner sign-off for each step is a requested coordination gate that must be assigned, not a current CODEOWNERS requirement; PR3 gets ordinary trust-change/high review, not a fabricated special class.

    6. Open decisions for the Manager

    1. Accept three Fractal code PRs plus external retirement receipts, or identify current supported external signer source/site that justifies PR2? Do not restore deleted service just to satisfy the old plan.
    2. Who owns evidence/trust review and signs the per-step rollout decision? Historical admission owner and dotfiles Manager do not establish that role.
    3. What recorded human disposition permits this unavoidable high-floor rename to land without self-editing review rules? Does Q27's answer explicitly cover that route?
    4. Which sites must supply activation/process or retirement receipts (including log/presign/queue timers and hosted workflow bases), and who collects them? No live-host status was inspected here.
    5. What observation window and historical-replay support contract permits PR4? Recommended: current tools require post-move bases; historical revisions are decoded by their own base tools. Keep the bridge until that is proved and approved.
    6. If a live external signer exists, resolve its contraction PR count before PR1: clean removal across two repositories cannot literally fit one final ordinary PR. Is a fifth narrowly scoped contraction PR acceptable, or should the obsolete signer remain retired?
    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  21. schickling-assistant commented on Oct 27, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 27, 2026
    ContributorAuthor

    Q27 decisions (dotfiles Manager agent/dotfiles/manager, message c8f68c153d7372e5), recorded by the Fractal rename agent:

    1. Three fractal PRs (expand, move, contract) plus a host retirement receipt. No supported signer exists, so there is no dotfiles signer PR.
    2. Evidence and trust review per step: agent/dotfiles/fractal-product-lead plus an independent security review at the exact head.
    3. Johannes's Q27 answer (Axe u2ddzm, answer 5i9b8z: rename-at-contraction including the trust-path migration) is the recorded human decision for the high-risk floor.
    4. agent/dotfiles/deployer collects the retirement receipts on dev3 and dev5. The receipt gates PR3.
    5. Observation window: 7 days after PR3 on all hosts that run it, before PR4.
    6. The signer stays retired; there is no fifth PR.
      PR1 (expand, dual-read) is in progress.
    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  22. schickling-assistant commented on Oct 27, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 27, 2026
    ContributorAuthor

    Q27 PR2 slot: signer retirement receipts from the Deployer (agent/dotfiles/deployer), recorded by the Fractal rename agent. Both hosts are clear, so the receipt gate for PR3 is satisfied.

    • dev5, 2026-10-27T16:18:33Z: dotfiles af6c79d0 (contains ad8f236e1e); system-65 → /nix/store/1p5wnjr2p9f0b75gd01ggbhfnq30rv3x-nixos-system-dev5-26.11.20260912.4ba99f3. fractal-signing units, timers, user units, user timers, unit files and processes: all 0.
    • dev3, 2026-10-27T21:04:29Z: dotfiles e06c0697 (main d54b92ce plus the bf7e8fe5 revert; contains ad8f236e1e); system-57 → /nix/store/wyllbmgvrfrpc4sfgpvj8laxxm1fsw4i-nixos-system-dev3-26.11.20260912.4ba99f3. Same probes: all 0.
      PR1 (expand) is Expand evidence configuration readers to .fractal (Q27 PR1) #4086, still a draft.
    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  23. schickling-assistant commented on Oct 29, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 29, 2026
    ContributorAuthor

    st→fractal migration mission: plan with dates

    Status: approved by the Manager (agent/dotfiles/manager) on 2026-10-29, with 4 corrections, which are applied below:

    1. The daily bump is the Deps Manager's dotfiles workflow (Manager decision 82f9e18f).
    2. STOP release criterion (e) is added.
    3. The Macs come after 11-06.
    4. Q30 is answered. Johannes chose versioned-new-plus-decoder.

    The Fractal rename agent (agent/compoundingtech/fractal-rename) leads the mission. Plan written 2026-10-29 ~22:30Z. All times are UTC. The facts behind it are in the read-only inventories /tmp/fr-q/plan-facts/{A..F}.md (fractal a5a13bf, dotfiles 149440ff, pty 284c3779, graph 81caf25f). No command ran on dev5.

    Inputs

    • Johannes's six scope items, relayed by the Compounding Manager (message 05ce096fc3f8409d).
    • Q27: .st/ → .fractal/ in 3 PRs.
    • Q28: the runtime unit, scope and slice names migrate after contraction.
    • Q29: rename st-ci-cache and accept one cold cache cycle. Johannes's note on Q29: "full proper rename, no residue".
    • The Manager's STOP 9accbcc7: no host pty binary change on any host.

    Date conflicts and which date wins

    1. st/st3 aliases. Rename Smalltalk to Fractal (product, binaries, crates, env, wire, state) #3032 says the sunset is about 2026-11-01; Johannes's item 2 says the shims warn until 2026-11-15. 2026-11-15 wins. The warning lands on 2026-11-01, and the shims are removed on 2026-11-16.
    2. Environment, wire and state bridges. Rename Smalltalk to Fractal (product, binaries, crates, env, wire, state) #3032 says contraction is about 2026-11-01. That cannot hold:
      • ST_AGENT is still written everywhere (item 5).
      • The wire senders have not switched.
      • No host has a state-migration receipt; on dev3, smalltalk.service is still active and no receipt exists.
        The per-bridge dates below win. On 2026-11-01, only the bridges whose prerequisites are met contract: the release-artifact copies, the script-path wrappers (after the units call the new paths), and the st-test shim (if every base contains fix: expose fractal proof runner without breaking copy-only bases #4061).
    3. Q27 order: unchanged. PR1 (expand) merges by 2026-10-31. PR3 (move) is on 2026-11-01. PR4 (contract) is on 2026-11-08 or later. The Mergemaster extraction starts from a base that contains PR1 and keeps the dual read until PR4.

    Steps (in order; each step names its gate)

    # Date Step Gate / acceptance
    1 10-30 / 10-31 Q27 PR1 #4086 (.fractal/ first, .st/ fallback): merge main, then the Product Lead trust GO and an independent GO at the exact head Merge only in Nathan's protected-CI windows (minutes 00–20 of 00/06/12/18 UTC). The merged SHA becomes A1, sent to the Mergemaster agent
    2 10-30 → 11-01 Shim warning prerequisites: fix dotfiles graph-applier-monitor.sh:296-300, which exact-matches stderr; it would turn a warning into a failure. Then a fractal PR: an argv[0] dispatch that prints one stderr line, st/st3 is deprecated; use fractal (removed 2026-11-16). It never writes to stdout, so JSON modes stay clean Independent GO; no consumer matches stderr
    3 10-30 → 11-01 st-ci-cache rename (Q29): path, snapshot root and docs in one PR; the signing key stays Merge outside the protected windows; one cold cycle is expected
    4 11-01 Contraction batch 1: Q27 PR3 (move the 13 files); remove the release-artifact copies, the st-test shim and the script-path wrappers (each only if its prerequisite holds) contraction-wake mission 08:00Z
    5 11-01 → 11-07 fractalBinary cutover and the packages.fractal collision. Today, packages.fractal in fractal is a thin wrapper (bin/fractal → st3), and fractalBinary.enable = false fleet-wide. Change: packages.fractal becomes the full product package (bin/fractal plus the st/st3 shims); packages.st3/small-talk become aliases; Agent Policy wraps fractal (the gateway already has a fractal guard); then fractalBinary.enable = true Agent Policy owner review. Preflight on each host: no retired ~/.local/bin/fractal symlink that would shadow the new binary
    6 11-02 → 11-07 State migration (item 3): land dotfiles#7197, then per host: Deployer hold → backup → fractal migrate host → receipt → PRAGMA user_version=20 → release. Order: dev5 (canary) → dev4 → dev3 → Macs. The Macs come after Johannes is back on 11-06; the Fractal rename agent proposes the Mac slot to the Manager Manager GO plus Deployer T0 per host. On dev3, a stale ~/.local/state/fractal/.presentation.json.tmp.221987.1 makes the mover refuse a nonempty destination. It is removed inside the per-host backup step, after the backup receipt, never as a standalone deletion
    7 after 6 q21 HM options: services.fractal.* with mkRenamedOptionModule aliases; the dotfiles owners move 28 files after the last host cutover
    8 11-03 → 11-10 pty upgrade + #4147 LEGACY removal (item 4), see the section below STOP 9accbcc7 released by the Manager
    9 11-01 → 12-06 ST_AGENT → FRACTAL_AGENT (item 5), 4 phases, see below per phase
    10 11-08 Q27 PR4: remove the .st/ fallback 7 days after PR3
    11 11-08 → 11-22 Q28 runtime names: dual recognizers in fractal and dotfiles (drop-ins, transition gate, resource collector, tile parser with a security review) → producers switch to fractal-* → old PTY scopes drain → remove the old recognizers after contraction
    12 11-16 Remove the st/st3 shims; switch the wire senders after every member accepts both; then remove the receiver accept-both sender switch only after receipts that each member accepts both
    13 rolling Daily auto-bump (item 6), see below owner: Deps Manager
    14 11-22 → 12-06 No-residue sweep (Q29 note): rename every class-(a) item (list below) behind bridges; a decision request for the class-(b) items Johannes decides class (b) (one Axe question)

    Step 8: host pty upgrade and #4147 LEGACY removal

    Facts:

    • The first pty commit that writes daemonBootId is 7df95468 (2026-10-14), plus 9baf6c7, which requires the boot evidence. Neither is in a tag; the newest tag is v0.13.0-rust.3 (2026-10-11).
    • The dotfiles host pin 063ff7f does not contain 7df95468. dev3 runs 0.13.0-rust+063ff7f (store 6sxmr3ri…). dev5 uses the same source pin; its live version was not observed.
    • The LEGACY helper is crates/fractal-runtime/src/pty.rs:1202-1230. It has no counter or log: a fallback admission looks like an ordinary Match.

    Steps:

    1. fractal PR: a bounded counter and a log at the LEGACY arm (pty.rs:~1227), exported in the daemon metrics. This needs no STOP release.
    2. pty owner: tag a release that contains 7df95468 and 9baf6c7 (e.g. v0.13.0-rust.4).
    3. STOP release criteria for the Manager:
      • (a) the fleet-compat test of fractal#4180 is green at the candidate pin;
      • (b) the counter from step 1 is deployed, so legacy use can be measured;
      • (c) canary host first: dev5, with the session list, the pty server PIDs and a smoke test equal before and after (precedent 103eedef);
      • (d) the mailbox: admit legacy PTY records without daemonBootId via start token #4147 LEGACY path stays in place;
      • (e) the pty pin is a tag (v0.13.0-rust.4 or newer), not a bare commit, and each host gets its own Manager exception request with the Deployer's T0.
        The Manager releases the STOP for dev5 only when (a) and (b) are evidenced.
    4. Roll out per host: dev5 → dev4 → dev3 → Macs, each with a Manager exception and a receipt.
    5. Old PTY records drain; the old daemons keep running without a boot id. Observe: on every host, scripts/check-pty-boot-identities.py reports 0 records without a boot id, and the LEGACY counter stays 0 over 7 days that cover every seat binding.
    6. Remove the LEGACY path. Earliest date: 7 days after the last host upgrade.

    Step 9: ST_AGENT → FRACTAL_AGENT

    Already in place: the fractal launcher, direct OMP and Axe child processes write both names. The Agent Policy guards (policy-lib.nix:53-57, st-person-actor.nix:666-668) accept either name and reject a mismatch.

    • Phase 1 (by 11-08): every reader prefers FRACTAL_AGENT. dotfiles#7773 covers 8 files. Still old-only: dotfiles about 33 more files (axe, nix-convergence, vista, janitor, op-proxy, playwright-tools, flakes/fractal and others), fractal 4 (tui lib.rs:841, delivery-probe, discord-bridge, boot-canaries), graph 5. materialize.rs:445-468 must write both names.
    • Phase 2 (by 11-15): instructions, skills and policy text say FRACTAL_AGENT; the rule "literal ST_AGENT=agent/" becomes "FRACTAL_AGENT=agent/". Some of these are agent-ecosystem docs and need an Agent Policy owner review.
    • Phase 3 (11-22): stop writing ST_AGENT, canary dev5 first.
    • Phase 4 (12-06): remove the ST_AGENT reads and the ST_* env dual-read bridge (arn:lmig:smalltalk:2026-10-16-env-fractal-dual-read, 501 lines).

    Step 13: daily auto-bump (fractal, pty, axe, omp) with a dev5 canary

    No such pipeline exists today. Related parts:

    • Deps Manager: weekly freshness (Monday 07:00Z).
    • upstream-pin-drift.yml: a daily drift report, not a bump.
    • The smalltalk-repin mission.
    • st-train: config expired 2026-10-24 and excludes dev5.
    • Evergreen: archived.

    The four inputs differ:

    • fractal: a megarepo member pin;
    • pty: a root flake input, blocked by STOP 9accbcc7;
    • omp: a version plus binary hashes in flakes/external/omp;
    • axe: in-repo, so there is nothing to bump.

    Decided (Manager decision 82f9e18f):

    • The Deps Manager runs a scheduled dotfiles GitHub workflow that bumps fractal and omp. Its PR is due 10-31.
    • axe is dropped from the bump. pty is gated on smalltalkPtySkew and on STOP 9accbcc7.
    • Agent Policy appends the attestation commit.
    • The Fractal rename agent sent the Deps Manager the bump-hold list for the migration steps (message 176f7a09b95e3fe4).

    Step 14: "no residue": classification (PlanFactsB, /tmp/fr-q/plan-facts/F.md)

    • (a) Rename with a bridge (planned):

      • x-st3-* headers, st3.client.*, st3.cap.* (grants reissued), the unsigned response-envelope st3.v1;
      • the WIT st2:* package names, docs/st3/, .st3-documents, the soak units and plist;
      • the Claude plugin st-channel@st, codegen markers, report schema ids (st3-migrate-report.v1), telemetry names (dashboards accept both);
      • the Storybook Alchemy stack and Worker (IaC adoption), Apple ids (R13 re-pair);
      • the state paths (step 6), scripts/r15-rename-*, smalltalk-graph (Johannes renames it as admin), nixpkgs/smalltalk/, services.smalltalk.*, the st3-migrate binary, the @smalltalk/st3-client and @st3/sdk packages, the env names ST_INSTANCE/ST3_DAEMON_WAIT/~/.st-instance (visible in fractal --help today).

    • (b) Only by breaking durable identity:

      • st3.v1 in signed claim and peer envelopes;
      • the hash and idempotency domains (st3.replica-batch.v1, st3.idempotency.v1, st3.claim-request.v1);
      • signed evidence with the old predicate URI;
      • agent/st/assistant, which needs a subject-successor primitive that does not exist.

      Decided (Q30 2k7p5w, answer 47r1ht: versioned-new-plus-decoder):

      • new writes use fractal.v1 and fractal.* domains, with an accept-both rollout;
      • permanent decoders read the old bytes;
      • a design issue for a subject-successor operation comes before agent/st/assistant moves.

    • (c) Historical, kept byte-for-byte: release notes, receipts, recorded payloads, old commits.

    Already done since 10-27

    #4089, #4140 (residue, env fallbacks), effect-utils#2173. dotfiles#7773 is with ci-manager. dotfiles#7750: constitutional consent verified at b056bf01. A brief went to the smalltalk-graph agent (text, links, genie-fractal repin). The dev3 and dev5 signer retirement receipts are recorded on #3032.

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  24. schickling-assistant commented on Oct 30, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 30, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename): A1 done. Q27 PR1 #4086 (evidence configuration readers prefer .fractal, with .st fallback) merged at 2026-10-30T06:25:32Z, merge commit 69ee94f, head c624159. The PR entered the merge queue at 06:01:21Z, inside the 06:00Z window. Next: a follow-up PR on main converts scripts/classify-risk-test:78,80 to preferred reads (Product Lead condition), and it must land before Q27 PR3 adds .fractal config files. Also merged today: #4292 (fractal migrate host refuses mounted product roots).

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  25. schickling-assistant commented on Oct 30, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 30, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename): the Product Lead condition for Q27 PR3 is met. #4315 merged at 2026-10-30T07:42:24Z (merge commit fe75f0f). The tests in classify-risk-test and review-test now read live config through the preferred-first production readers, and a real person's name is removed from comments in evidence-verify-test. Q27 PR3 may add the .fractal config files on 11-01.

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  26. schickling-assistant commented on Oct 30, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 30, 2026
    ContributorAuthor

    Fractal rename agent (agent/compoundingtech/fractal-rename): store-dir source prerequisites are merged before the 2026-11-03 deadline. #4303 merged at 2026-10-30T10:15:25Z (0c4c67b); #4308 merged at 2026-10-30T10:58:18Z (8b31829). The Compounding Manager confirms both ship with the next release. This completes source preparation, not host rollout or state relocation. The dev3 order remains product-root cutover with no mounts, then the separately authorized database-store move. Host cutovers still require the Manager GO and Deployer T0; the pty STOP is unchanged.

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree smalltalk/main

  27. schickling-assistant commented on Oct 30, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 30, 2026
    ContributorAuthor

    Rename of the peer envelope label st3.v1 (new writes only; history is never rewritten): compatibility findings with evidence, for @myobie.

    Wire-label sites (can flip reader-first): PEER_API_VERSION (crates/smallclaims/src/sync/mod.rs:445), response_body.rs:204/226, read_deadline.rs:205, mailbox.rs:199, fractal-peer peer.rs:1659, and the client-fabricated error envelopes (fractal-client lib.rs:4305, codegen lib.rs.in:2692). Four readers compare exactly and would refuse a new value: peer.rs:957, sync/worker.rs:3010 and 4208, worker/answers_check.rs:313. Two fixed accept sets also need the new value: fractal-secrets client.rs:1733 and scripts/fractal-discord-bridge.

    Blockers, where the name is not just a label:

    1. SCHEMA_NAME = "st3.v1" is serialized into Registry, and Registry::digest() hashes it (fractal-schema lib.rs:461-465, 1208). That digest flows into compatibility_digest and then into the per-peer replication_peers.schema_digest. During a mixed rollout, check_fleet_registry_conn (identities.rs:303-307) would refuse identity writes with incompatible-fleet, and same_registry (smallclaims store.rs:7399) would suppress graph heals.
    2. NormalizedIntent.schema is part of the owned-set idempotency hash (fractal-store store.rs:3020-3032), so a retry across the cutover would give idempotency-mismatch.
    3. daemon.started claim bodies persist schema and schema_digest (fractal main.rs:6509-6514). Old bytes stay verifiable, because claim and envelope hashes are content-derived.

    The hash and signature domains (st3.replica-batch.v1, st3-replica-envelope-v1, st3-replica-record-v1, st3-replication-v1, st3-member-v1, st3-local-storage-v1) stay frozen.

    Proposed sequence:

    • E0: decouple the digests from the display name. Pin the Registry digest input to the frozen st3.v1 (or exclude name), keep schema out of the idempotency tuple (or write a frozen value there), and decouple the daemon.started field.
    • E1: widen the four exact-compare readers and both accept sets, then release and deploy fleet-wide.
    • E2: flip the wire-label writers.

    Question: is E0 acceptable as described? Or should the registry and fleet identity instead get an explicit versioned domain in the digest input (for example a REGISTRY_DOMAIN), which is a separate versioned-contract design?

  28. schickling-assistant commented on Oct 30, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 30, 2026
    ContributorAuthor

    Notice: peer envelope version st3.v1: decision and rollout order

    The completion rule for this rename is zero active legacy names. For the signed peer-envelope version string st3.v1, the earlier freeze recorded in this issue is overridden for new writes only; immutable history is never rewritten. The decision is a versioned transition.

    Order — each step completes before the next begins:

    1. Accepting readers first. Every peer/response reader accepts both st3.v1 and fractal.v1. Current builds reject any other version at crates/fractal-peer/src/peer.rs:956, crates/smallclaims/src/sync/worker.rs:3010 and :4208, and crates/smallclaims/src/sync/worker/answers_check.rs:313. Ship, release, and roll to every fleet member; senders stay unchanged meanwhile.
    2. New writer. Only after every member is recorded on an accepting release, writers switch crates/smallclaims/src/sync/mod.rs:445 (PEER_API_VERSION) and the literal envelope writers (for example crates/fractal-peer/src/peer.rs:1658).
    3. Old bytes verifiable forever. st3.v1 remains a permanently accepted read spelling; no stored envelope, signed answer, or history is rewritten. Signatures cover exact body bytes, so existing signatures stay valid with no re-signing.

    Frozen cryptographic domains (not renamed, no transition): st3-member-v1 and st3-replication-v1 (crates/smallclaims/src/sync/mod.rs:81, :51) and the hash domains st3.replica-batch.v1, st3.idempotency.v1, st3.claim-request.v1 (crates/smallclaims/src/hash.rs:24, crates/smallclaims/src/store.rs:9711, :9736) — changing these would change digests of existing history.

    Compatibility notes for steps 1-2: the version string sits inside the signed body bytes (content-covered signatures; accepting readers preserve all old signatures), and the same spelling is also the claim-registry name (crates/fractal-schema/src/lib.rs:26) hashed into the registry digest (:462-465) that replication exchanges compare (crates/smallclaims/src/store.rs:7398-7400) — renaming that registry name is a separate decision, since mixed-version members then compare as unsettled until the roll completes, and stored graph rows keep the schema string they were written with.

    Open item: the registry-name use of the same spelling (last paragraph) is not decided by this notice. It goes to the contract owner with this evidence before any writer changes it.

    Posted on behalf of @schickling
    field value
    agent_identity agent/dotfiles/fractal-product-lead
    session 01a1b525
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.12.5
    agent_runtime OMP 18.12.5
    agent_model anthropic/claude-opus-5-5
    worktree unknown

  29. schickling-assistant commented on Oct 30, 2026

    @schickling-assistant
    schickling-assistant
    on Oct 30, 2026
    ContributorAuthor

    Decision needed (contract owner): the registry-name use of st3.v1

    The same spelling is the claim-registry name (crates/fractal-schema/src/lib.rs:26). Registry::digest() hashes it, and replication peers compare that digest (crates/smallclaims/src/store.rs:7398-7400). Two options:

    • A. Carve-out (recommended). The digest input keeps the literal st3.v1 as a frozen hash input, in the same class as the frozen hash domains above. Only the display and wire name changes. No mixed-version window in which members compare as unsettled; stored graph rows stay valid; no new reader code.
    • B. Versioned registry identity. A dual-digest reader accepts both names, it is rolled to every member, then the writer switches. Mixed-version members compare as unsettled until the roll completes.

    Question: is A acceptable? Until this is answered, only the registry-name change waits; the four peer-reader changes in the notice above continue.

    Posted on behalf of @schickling
    field value
    agent_identity agent/dotfiles/fractal-product-lead
    session 01a1b525
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.12.5
    agent_runtime OMP 18.12.5
    agent_model anthropic/claude-opus-5-5
    worktree unknown

  30. schickling-assistant commented on Nov 1, 2026

    @schickling-assistant
    schickling-assistant
    on Nov 1, 2026
    ContributorAuthor

    @myobie, a ping on the open contract-owner decision from 2026-10-30 (#3032 (comment)): the registry-name use of st3.v1.

    • A. Carve-out (recommended there): Registry::digest() keeps the literal st3.v1 as a frozen hash input; only the display and wire name changes. No mixed-version window, stored graph rows stay valid, no new reader code.
    • B. Versioned registry identity: a dual-digest reader rolls to every member first, then the writer switches; members compare as unsettled during the roll.

    Why now: v0.3.24 (published today) carries the physical fractal binary and every Stage 0 reader, and Johannes asked to move all remaining rename work that the gates allow. This answer gates two remaining items: separating the registry digest from the name, and the peer envelope writer. A one-letter reply (A or B) is enough.

    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/compounding-manager
    session 01a1d992
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree unknown

  31. schickling-assistant commented on Nov 1, 2026

    @schickling-assistant
    schickling-assistant
    on Nov 1, 2026
    ContributorAuthor

    Host cutover runbook (extracted from fractal cbf822e3 source with file:line citations by a read-only subagent, posted by Fractal rename agent agent/compoundingtech/fractal-rename). Source evidence only; nothing here was executed.

    Known gaps, owned as stated in the message to Deployer: (1) macOS Home Manager replication label not recognized by the mover; (2) dev3 st-chatgpt units depend on smalltalk.service.

    Runbook

    Fractal host cutover runbook

    Evidence scope and unresolved prerequisites

    All Fractal references below are at cbf822e3f4d1ab950b17ba89b4f8e511c64c859f. Paths without a repository prefix are Fractal paths unless marked dotfiles. No host commands, builds, tests or migrations were executed.

    Artifact creation limitation: local://cutover-runbook.md was not written: the assignment prohibits writes and no write tool is exposed. Save this report there from the main agent.

    Dotfiles source limitation: the available refs/heads/main worktree is old and lacks the modern modules; no shell/git/gh execution tool is exposed to fetch main. Modern source was read from the existing deployment branch schickling-assistant/2026-11-01-fractal-cbf822e3, Agent Policy branch schickling-assistant/2026-11-01-fractal-launchd-phase-registration, and PR #8077's GitHub diff. These establish the producer and phase design, but are not a verified fresh origin/main snapshot. PR #8077 is OPEN and DRAFT, head schickling-assistant/2026-11-01-fractal-linux-phase-units, base Agent Policy's macOS branch; its body reports head 0c8db84cf4cc6fc284384143f453680aef65a1ba. Do not describe its Linux fixes as already merged.

    Shared rules, preflight and outputs

    1. Preserve recoverable matching state, keys, old binary and installation ownership before doctor/restart/export. Do not replace a Nix-owned installation with the archive installer. (docs/site/guides/upgrading.md:11-18.)
    2. Stage the pinned package via the owning Home Manager configuration with services.smalltalk.fractalMigration.phase = "stage";; native unmanaged installs instead use fractal service install --stage-fractal. Native staging installs disabled target daemon/replication definitions, does not stop legacy services, and rejects active targets/nondefault roots. (nix/hm-module.nix:173-180; docs/st3/macos-installation.md:87-106.) The activation command itself depends on the owning dotfiles deployment entry point, not supplied or verified here.
    3. Keep the legacy daemon running before dry-run and migration: the mover needs its API. Target definitions must already be installed, disabled and stopped; one installed legacy daemon only; destinations must be absent or empty ordinary directories. (crates/fractal/src/migrate_cli.rs:459-491; crates/fractal/src/migrate_cli/native.rs:109-142; crates/fractal/src/migrate_cli.rs:410-424.)
    4. No mounts may exist at/below either source or destination product root for initial migration. Restore mounted legacy data into ordinary legacy directories and move/unmount the mount first; restart legacy daemon before dry-run. Do not simply mount populated data at the target. Exact dataset-specific preparation requires the host's mount inventory and preservation plan. (docs/st3/macos-installation.md:108-134; crates/fractal/src/migrate_cli/mounts.rs:19-32,88-103.)
    5. If the running daemon has up --config, --state-dir, or --store-dir, append the same corresponding flags to both migrate commands below. They describe the running daemon; they do not update service definitions. A configured store must already be reachable; external mounted stores outside product roots are allowed and untouched; an ordinary store below the legacy root moves with that root. (crates/fractal/src/migrate_cli.rs:25-41,136-172; docs/st3/macos-installation.md:136-154.)
    6. Quiescence is strict: checkpoint pending must be null; replication pending_records zero; first_sync, if present, verified; every observed peer worker idle/backoff. Dry-run checks this and actual cutover checks it again. A failed check means wait/resolve, not bypass. (crates/fractal/src/migrate_cli/native.rs:250-262; crates/fractal/src/migrate_cli.rs:537-539.)

    After backup, the documented diagnostics are:

    fractal --version --json
fractal doctor --json
fractal service status
fractal agents ls
fractal replication status

    Compare CLI build to daemon machine_version; these are post-preservation diagnostics, not a substitute for backup. (docs/site/guides/upgrading.md:32-42.)

    Three different persisted/output objects—do not confuse them

    • Command stdout from fractal migrate host --json: fields migration, host, status, manager, local_api, effective (with memory_swap_max, memory_low), gap_ms. Successful values include status completed, local_api local API listening, manager systemd-user or launchd-user. Linux effective protection must match before and after; macOS protection fields are null. (crates/fractal/src/migrate_cli.rs:59-74,520-526,593-598; crates/fractal/src/migrate_cli/native.rs:145-146,227-248.) Redirect stdout to an operator-chosen evidence file; the mover does not choose a JSON receipt output pathname.
    • Root markers: ${XDG_CONFIG_HOME:-$HOME/.config}/fractal/.fractal-migration-completed and ${XDG_STATE_HOME:-$HOME/.local/state}/fractal/.fractal-migration-completed. Each is plain text, exactly arn:lmig:smalltalk:2026-10-16-state-dirs-fractal plus newline, not JSON. (crates/fractal-client/src/product_dirs.rs:9-13,39-47; crates/fractal/src/migrate_cli.rs:99-104,324-331,575-579.)
    • Undo/commit journal: ${XDG_CONFIG_HOME:-$HOME/.config}/.fractal-host-cutover.json, fields include migration, services, pairs, moves, emptied, receipts, links, config_fence, committed, before, after, gap_ms. Do not delete it to bypass recovery. (crates/fractal/src/migrate_cli.rs:99-104,247-268,309-320,441-458.)

    Root/marker verification commands, derived directly from those paths:

    C="${XDG_CONFIG_HOME:-$HOME/.config}"
S="${XDG_STATE_HOME:-$HOME/.local/state}"
readlink "$C/st3"
readlink "$S/st3"
echo 'arn:lmig:smalltalk:2026-10-16-state-dirs-fractal' | cmp - "$C/fractal/.fractal-migration-completed"
echo 'arn:lmig:smalltalk:2026-10-16-state-dirs-fractal' | cmp - "$S/fractal/.fractal-migration-completed"

    The bridges are intentional; do not remove them. Root exchange and marker publication occur in crates/fractal/src/migrate_cli.rs:553-579.

    Linux non-dev3

    Ordered execution

    1. Complete shared backup, stage activation, mount/path checks and diagnostics above. Inspect both legacy aliases to resolve duplicate ownership:
    systemctl --user show smalltalk.service st3.service smalltalk-replication.service st3-replication.service fractal.service fractal-replication.service --property=LoadState --property=ActiveState --property=UnitFileState
fractal migrate host --dry-run
fractal migrate host --json > "$HOME/fractal-host-cutover-receipt.json"

    The inspection properties and aliases match native discovery (crates/fractal/src/migrate_cli/native.rs:53-68,99-105). The receipt pathname above is an operator choice. Append matched daemon overrides when needed (crates/fractal/src/migrate_cli.rs:25-41).

    1. Do not manually stop the recognized legacy daemon/worker immediately before migrate. The mover disables legacy units, stops running auxiliaries in reverse order then daemon, holds state/store fences, swaps roots/drop-ins, publishes markers, starts the target daemon, checks memory protection and same-node local API, commits, retires old definitions, enables targets and starts target auxiliaries. (crates/fractal/src/migrate_cli.rs:529-598,645-655.) It recognizes smalltalk-apply.service, but not arbitrary graph-owned monitors or Fabric carrier services. Those remain owner-managed. (crates/fractal/src/migrate_cli/native.rs:99-105; release-notes/migrate-host-worker-control-dropins.json:9.)

    2. Run root-marker verification above and:

    systemctl --user status fractal.service fractal-replication.service
systemctl --user show fractal.service --property=MemorySwapMax --property=MemoryLow
fractal --version --json
fractal doctor --json
fractal agents ls
fractal replication status

    Only require replication.service if that host actually has an enabled worker; discovery adds targets for installed legacy auxiliaries, not every host unconditionally (crates/fractal/src/migrate_cli/native.rs:127-141). Receipt protection values are the mover's stronger effective-cgroup comparison (native.rs:227-245).

    1. After successful migration, before the next Home Manager activation, change services.smalltalk.fractalMigration.phase = "completed";, with PR #8077 merged/included in the deployed dotfiles closure. Its fleet.nix:10-12,64-101 selects fractal daemon/worker dependencies and default.nix:56-59,282-299,401-413 avoids resurrecting a stray smalltalk unit. This is required in addition to the product module's phase support.

    Rollback

    fractal migrate host --rollback --json

    Pass the same relevant daemon override flags. This is only interrupted pre-readiness rollback. The mover automatically attempts rollback if swap/start/probe fails before commit. An existing interrupted journal requires explicit rollback before retry; committed readiness permanently refuses rollback (crates/fractal/src/migrate_cli.rs:441-458,505-521). Any product-root mount/submount refuses before stopping services; no journal also refuses. Invalid/mismatched journal migration/service/path plan refuses. (migrate_cli.rs:426-458,465; migrate_cli/mounts.rs:99-100.) Rollback restores moved paths and prior legacy enablement/running state, disables target units and removes the interrupted journal (migrate_cli.rs:601-642).

    dev3: complete host cutover first, then database-only store relocation

    Cutover stage

    Use the Linux sequence without mounts under either product root. Do not set a pre-cutover store path inside the future fractal destination: preflight rejects it (crates/fractal/src/migrate_cli.rs:153-155). Resolve any existing dev3 dataset mount/data preservation separately first, per the shared mount rules.

    The mover does not manage the dev3 ChatGPT adapter/tunnel. Because those units are separately produced and the adapter Wants/After still names smalltalk.service in the inspected snapshot, coordinate with their owner before activation; do not assume #8077 migrates them. (dotfiles nixpkgs/home-manager/dev3.nix:835-866; mover allowlist crates/fractal/src/migrate_cli.rs:430-436.)

    Relocate the SQLite trio after committed cutover

    The documented product procedure is daemon-only stop, preserve/move the three database files together, keep state_dir at the product root, set explicit store_dir, restart (docs/st3/macos-installation.md:156-164). The assignment additionally specifies checkpoint TRUNCATE and copy. The following shell sequence implements that operator policy; the literal dataset/mount command and declarative store-config update cannot be made host-exact without dev3's approved dataset identity and activation mechanism.

    Important: Linux dotfiles fleet workers carry PartOf and Requires on the daemon (PR #8077 fleet.nix:72-81), so systemctl stop fractal.service can also stop its dependent replication worker. 'Stop only daemon' means do not separately migrate/copy worker state; it does not prove the worker process remains running. Verify/restart it afterward.

    S="${XDG_STATE_HOME:-$HOME/.local/state}"
STATE="$S/fractal"
STORE="$STATE/store"
systemctl --user stop fractal.service
sqlite3 "$STATE/claims.sqlite3" 'PRAGMA wal_checkpoint(TRUNCATE);'

    Require a nonbusy successful checkpoint before continuing. Preserve the original trio and do not run another writer. Mount the approved dataset at $STORE now, without hiding any unrelated existing migrated files. The exact mount command is a missing host prerequisite, not something migrate host performs (docs/st3/macos-installation.md:118-125,156-164). Then:

    for f in claims.sqlite3 claims.sqlite3-wal claims.sqlite3-shm; do
  if test -e "$STATE/$f"; then cp -p "$STATE/$f" "$STORE/$f"; fi
done
sqlite3 "$STORE/claims.sqlite3" 'PRAGMA integrity_check;'

    Require ok. WAL/SHM can legitimately disappear after a successful checkpoint/SQLite close; preserve/copy each existing member, never a separately captured live WAL. The conditional file handling and SQLite commands are operator-derived, not quoted product automation. Do not fabricate empty WAL/SHM files. Configure the actual owning daemon configuration with an absolute store_dir = "$HOME/.local/state/fractal/store", retaining root state_dir; do not move identity, sockets, logs, locks or PTY state into the dataset (docs/st3/macos-installation.md:159-164). Because Home Manager owns/fences config, make this through its actual configuration producer, not an assumed persistent hand edit (crates/fractal/src/migrate_cli.rs:333-348; nix/hm-module.nix:398-410).

    systemctl --user start fractal.service
systemctl --user start fractal-replication.service
fractal doctor --json
fractal replication status
fractal migrate host --dry-run

    The final committed dry-run must use current effective config/override flags. Only the exactly configured store mount is allowed for committed reruns; every other product-root mount still refuses (docs/st3/macos-installation.md:166-172). Initial migration receipts are unchanged. Rollback is already forbidden after readiness; unmounting does not reopen it. Do not start an older binary on the new store as an improvised rollback (docs/site/guides/upgrading.md:44-48).

    Completed phase

    Migrate first, completed activation second, same as Linux. The dataset store configuration must be carried by the owning completed configuration before its daemon restart; do not allow activation to erase store_dir or launch an empty root database. Exact approved dev3 mount/guard/config producer needs confirmation from the deployment packet, not from guessed commands.

    macOS

    1. Preserve existing app/state/keys first. Physical executable at this pin is ~/Applications/SmallTalk.app/Contents/MacOS/fractal; bin links can point there. Installer updates do not restart services/seats; direct loaded definitions must be stopped if installation needs to rewrite executable paths; HM wrappers are retained unchanged (docs/st3/macos-installation.md:3-18). Installation and cutover are separate transactions.
    2. Stage using the owning HM phase or, for native-managed definitions:
    "$HOME/Applications/SmallTalk.app/Contents/MacOS/fractal" service install --stage-fractal

    This native command is not a replacement for Home Manager activation on an HM-managed host (docs/site/guides/upgrading.md:18; docs/st3/macos-installation.md:87-106).
    3. Home Manager macOS worker handoff gap: the mover recognizes legacy replication label com.compoundingtech.st3.replication, not org.nix-community.home.smalltalk-replication (crates/fractal/src/migrate_cli/native.rs:156-162). Agent Policy's phase branch explicitly uses the latter for legacy/stage and com.compoundingtech.fractal.replication for completed (dotfiles fleet.nix:102-114). Thus the mover does not stop/retire that HM legacy worker or start its replacement. The operator/owner must stop/unload it, arrange a disabled/unloaded target worker, and retire/adopt it with completed activation. Do not claim migrate host handles this label.

    For an HM-managed Mac, stop that worker before dry-run; leave the daemon loaded/running:

    launchctl bootout "gui/$(id -u)/org.nix-community.home.smalltalk-replication"
fractal migrate host --dry-run
fractal migrate host --json > "$HOME/fractal-host-cutover-receipt.json"

    If bootout reveals no such job, establish actual ownership instead of blindly ignoring an error. Stopping the worker may make the strict idle/backoff observation fail; the source does not supply a guaranteed safe bypass. If dry-run refuses because the worker is unobserved, the exact HM Mac choreography is blocked pending the owner's runtime handoff plan. Do not force progress or falsify the receipt. (native.rs:250-262.) Native-managed Macs with the recognized legacy replication label do not require this extra HM-worker step.

    1. The mover bootouts recognized jobs, enables/bootstrap/kickstarts the target daemon, probes /v1/health for the same node, commits, then starts recognized auxiliaries (native.rs:168-211; migrate_cli.rs:529-598,645-655). Verify markers and:
    launchctl print "gui/$(id -u)/com.compoundingtech.fractal"
fractal --version --json
fractal doctor --json
fractal agents ls
fractal replication status
    1. Change services.smalltalk.fractalMigration.phase = "completed"; only after migrate host succeeds, then activate the dotfiles configuration including Agent Policy's launchd phase registration. Verify exactly the intended worker after the owner handoff:
    launchctl print "gui/$(id -u)/com.compoundingtech.fractal.replication"
launchctl print "gui/$(id -u)/org.nix-community.home.smalltalk-replication"

    The first should exist when enabled; the second should be absent. This is the desired acceptance check, not a claim it was exercised. PR #8077's fleet-runbook.md:461-466 documents these phase-selected labels; Agent Policy's fleet.nix:102-114 produces them.

    Rollback command and all refusal conditions are shared with Linux. macOS app backup restore is not a database/host-cutover rollback (docs/st3/macos-installation.md:56-65,80-84).

    Must migration precede completed?

    Yes, unequivocally. Product option docs say select completed after migrate host succeeds (nix/hm-module.nix:173-180). Completed activation requires both exact receipts, migrated directories, persistent config fence and inactive legacy daemon, otherwise emits 'Run fractal migrate host first' (nix/hm-module.nix:112-117,306-312). Conversely, legacy/stage activation after receipt publication refuses and asks for completed (nix/hm-module.nix:313-319). The intended order is stage activation → dry-run → migrate → completed activation, with no intermediate stage reactivation after commit. Dotfiles #8077 plus Agent Policy Mac phase registration must be included before completed activation.

    Can other peers remain on b5af696 and st3 directories?

    Directory cutover is host-local; this does not itself require simultaneous directory renames on peers. The mover discovers roots from the local HOME/XDG environment and only calls the local Unix API; remote endpoints and named instances refuse (crates/fractal/src/migrate_cli.rs:87-104,280-292). It renames existing state without rewriting history or database/claim schemas, and changes no coordination rules (release-notes/fractal-host-cutover.json:4-6). Replication makes logical authority equal, not SQLite byte-identical (docs/st3/replication.md:11). Fabric readers accept both namespace spellings while default writers retain st3 (docs/st3/replication.md:29). Therefore peers need not use the same local state directory pathname. This conclusion is an inference grounded in those explicit contracts, not an exact-version integration result.

    Do not elevate that to a blanket verified cbf822e↔b5af696 compatibility guarantee. The guide recommends same-release fleets and says patches do not promise mixed-build compatibility (docs/site/guides/upgrading.md:9). The fleet policy requires rolling compatibility/capability gating but explicitly records incomplete compatibility proof coverage (docs/st3/compatibility.md:3-22,196-225). No exact b5af696/cbf822e3 rolling-runtime test was located or run in this investigation. The supported narrow answer: leaving peers' dirs at st3 is not a blocker; allowing those exact binaries to coexist still requires the release/compatibility evidence from the broader deployment packet. Local migration also refuses active/unobserved sync even if peers continue running (native.rs:250-262).

    st-chatgpt producer and owner

    Available modern deployment snapshot:

    • Producer: dotfiles nixpkgs/home-manager/dev3.nix:835-900, not the shared smalltalk fleet module. systemd.user.services.st-chatgpt invokes ${smalltalkInput.packages.${pkgs.system}.st-chatgpt}/bin/st-chatgpt, client socket %t/st3-client.sock, loopback HTTP 127.0.0.1:8797, and Wants/After smalltalk.service (:835-850).
    • Tunnel producer: same file :851-900, depends on st-chatgpt, invokes the tunnel-client package through a shell wrapper and file-backed runtime API key, routes to the adapter's /mcp. Do not read or reproduce credential contents.
    • Explicit owner: dotfiles CREDENTIALS.md:297-300 says agent/compoundingtech/st-chatgpt and names both dev3-only HM user services. This satisfies ownership-by-documented-agent-area without inventing a CODEOWNERS match.
    • These are not in the mover service allowlist (crates/fractal/src/migrate_cli.rs:430-436); #8077 changes daemon/fleet units, not these producers. Their old daemon dependency is an owner handoff item before completed activation. A fresh origin/main fetch is still required to certify their exact current-main line positions/state.
    Posted on behalf of @schickling
    field value
    agent_identity agent/compoundingtech/fractal-rename
    session 01a16118
    agent_persona generalist
    agent_supervisor unavailable
    agent_tool OMP
    agent_tool_version 18.10.2
    agent_runtime OMP 18.10.2
    agent_model anthropic/claude-opus-5-5
    worktree unknown
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions