Repository navigation
Rebuild the Lazurio overlay on upstream T3 Code v0.1.5 - #149
Draft
immakermatty wants to merge 317 commits into
Draft
immakermatty wants to merge 317 commits into
immakermatty wants to merge 317 commits into
Conversation
…otgg#25928) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…otgg#25913) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
pingdotgg#25912) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…rs (pingdotgg#25859) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…n of effects (pingdotgg#25857) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
pingdotgg#25675) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…ft pane (pingdotgg#18492) Co-authored-by: maria-rcks <maria@kuuro.net>
…ingdotgg#26058) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…pingdotgg#26045) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…otgg#26046) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…otgg#26047) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…n drafts (pingdotgg#26050) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…otgg#26061) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…an effect (pingdotgg#26049) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…ad of stacking another (pingdotgg#26052) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…tgg#26042) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…g#25611) Co-authored-by: maria-rcks <maria@kuuro.net>
…gdotgg#25066) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: maria-rcks <maria@kuuro.net>
…ngdotgg#26064) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…otgg#19093) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Julius Marminge <julius0216@outlook.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…otgg#16653) Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
index.html loads the Environment's Lazurio shell (/.lazurio/shell.js, served by the Launchpad and absent outside Lazurio) and places its <lazurio-rail> beside #root and <lazurio-buddy> after it. #root is padded by the rail's width, T3's fixed-position sidebar is contained beside the rail, and the shell's colour roles derive from T3's own sidebar tokens so the shell follows every T3 theme. SidebarChromeHeader now renders the original top row and, under it, the shell's <lazurio-column-head>; undefined, the element renders nothing. Outside Buddy's bubble the Chat composer keeps the corner of Buddy's launcher free: while the shell draws the launcher, --lazurio-buddy-clearance on the document is the width it takes from the right edge, and the composer stack moves left, then narrows, just enough (LazurioPlatform F60, addendum of 2026-10-25). Unset, the composer stays where T3 puts it. On v0.1.3 both files merge cleanly: the new boot-error screens (pingdotgg#25317, pingdotgg#25345), the Inter font (pingdotgg#24865) and the sidebar footer changes (pingdotgg#25270) do not touch the seams. Settings is now a modal over the thread (pingdotgg#24847) and no longer renders its own column head; the thread and legacy sidebars still do. On v0.1.4: unchanged; the seams apply cleanly. The launcher clearance comes back to this row from row 28's commit, which carried it on v0.1.3. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…session On a Lazurio Environment every thread's agents work in the shared Environment browser through the agent-browser CLI, each thread in its own window. The CLI takes its session from AGENT_BROWSER_SESSION, so every process T3 starts for a thread carries the thread's session name: agent processes through a decorator around the server's AgentScope, Codex threads through their thread config (one app-server serves every thread), and a thread's terminals through the environment their shells start with. The variable only names the session. On v0.1.3 the three seams apply unchanged. AgentScope gained `stop` and a launch `unit` (pingdotgg#21299); the decorator spreads the inner scope and the launch, so upstream's reaping of an exited agent's systemd scope still receives its unit. The test mocks get `stop`, and the pass-through test now also checks that the decorated scope forwards `stop`. The terminal seam sits above upstream's shortened managed-install comment. Overlay comments are cut to the four-line limit. On v0.1.4: the Claude runner needs PortScanner.PortDiscovery since pingdotgg#22542, so the overlay's Claude test provides PortScanner.layerTest. pingdotgg#23913 only adds Delegate=yes to the agent scope; the AgentScope seam is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a Lazurio Environment the web client has no browser of its own: one shared Chromium runs on the Environment, and its view on the gateway shows one remote tab per address. The right panel shows the thread's tabs from the server's list (an event stream from the thread's holder file), each in a frame that stays mounted for instant switching; a new reveal opens the inline panel, a person's × lets go of the tab with Vrátit, and a plain click on a remote-tab link in the chat opens it in the panel. Another Lazurio Environment's tab opens as a tab of its own with a coloured border. Upstream's own server browser stays hidden there because the server omits capabilities.serverBrowser (row 10). The seams are one hook call and one wrapper in ChatView, the strip's title, icon, tooltip and menu in RightPanelTabs, and the surface kind in rightPanelStore. On v0.1.3 RightPanelTabs and rightPanelStore merge cleanly (pingdotgg#25464 moved the tab-list listeners, storage version is still 14). ChatView's only conflict is the import list next to upstream's new preview canvas imports (pingdotgg#25006); the hook call and the wrapper merge cleanly. ChatView now stays mounted, inert, under the Settings and Usage modals (pingdotgg#24847), so the thread's stream and frames stay live there. Overlay comments are cut to the four-line limit and the six effects of LazurioEnvironmentBrowser.tsx (stream, listeners, timer, draft lifecycle) carry justified react-effect-budget suppressions. The row imports LazurioNewTab.tsx and a singletonSurface case of row 13, so it typechecks and its browser tests run only with row 13. On v0.1.4: unchanged; the seam applies cleanly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a Lazurio Environment (marked by T3CODE_LAZURIO_FOLDER) T3's own browser tools drive the Environment browser, the one shared Chromium the agents already use through agent-browser, through a host that registers with the preview broker under upstream's server-browser client id once the Environment declares its browser. Upstream's server browser is never built there (a gate in server.ts) and the descriptor omits capabilities.serverBrowser, so clients open no server tabs. preview_open answers with the view of the tab, the address where a person sees it; another Environment's view is never loaded here, only handed to the person's panel. On v0.1.3 the broker protocol and the page engine's exports are unchanged; pingdotgg#25423 merged eight action tools into preview_act, which maps to the same broker operations, so the host needs no change. ServerBrowser.layer now needs PreviewAgentActivity (pingdotgg#25184), so the gate wraps ServerBrowser.layer.pipe(Layer.provide(Layer.merge(DesktopBrowserChannel.layer, PreviewAgentActivity.layer))) under upstream's memoization comment. The preview_open description takes upstream's shortened text (pingdotgg#24850) plus the overlay's view sentence. serverBrowser.test.ts gives its DesktopBrowserChannel mock the new `turn` and provides PreviewAgentActivity. The disabled server browser uses Effect.fn and liveTab uses Effect.undefined, for the new Effect diagnostics; overlay comments are cut to the four-line limit. The host imports row 11's threadTabs.ts, so this row alone does not typecheck. On v0.1.4: upstream added peerLinks, mcpModeLimitHeader and linkFence to the environment capabilities (pingdotgg#16655, pingdotgg#16695); they stay beside the overlay's serverBrowser gate. The row's later test change (agent-turn activity of the gated server browser) is folded in. On v0.1.5 ServerEnvironment.ts gains desktopAppChannelSwitch and threadProjectFromScratch (pingdotgg#26288, pingdotgg#26767) next to the overlay's import; serverBrowser is still left out only on a Lazurio Environment. Upstream's pre-commit hook now runs knip over the repository (pingdotgg#26167), so ENVIRONMENT_BROWSER_ENDPOINT, which nothing imports, is module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…file Each T3 Code thread keeps its tabs of the Environment browser only in its holder file, $XDG_RUNTIME_DIR/lazurio-browser/holders/t3-<thread>.json, the file the view's hub reads to keep a remote tab alive. The server reconciles every file with the hub's list of live tabs (at start, on change, every 30 s and before every write), serializes writes through one queue and never overwrites a file it cannot read, so a restart finds the tabs intact and T3's database stays upstream's. The web reaches a thread's tabs through /api/lazurio/thread-tabs (snapshot, event stream, hold, release) under upstream's preview scopes. holders.ts copies the Platform's holder helpers, and holders.test.ts runs the Platform's vectors against the copy. One line in server.ts joins the overlay's layer into layerMakeRoutes, where it shares the routes' one preview broker. On v0.1.3 the row merges cleanly: layerMakeRoutes gained GuestHttp (pingdotgg#24104) and the PreviewAgentActivity provide (pingdotgg#25184), and the overlay line still sits before the preview broker. Guest tokens never reach this route. ThreadTabs' methods use Effect.fn for the new Effect diagnostics, and comments are cut to the four-line limit; the holders.ts provenance line the contract pins stays. threadTabs.ts and the overlay layer import row 12's threadLifecycle.ts, so this row alone does not typecheck. On v0.1.4: upstream added the RemoteDelegation starter to the route layers (pingdotgg#16719); the overlay's layer follows it. On v0.1.5 upstream's pre-commit hook runs knip (pingdotgg#26167), so agentBrowserShutdownAction, which nothing imports, is module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…stops its agent's daemon
threadLifecycle.ts is the one adapter between the threads' tabs and T3's
orchestration: archiving or deleting a thread retires it, which removes its
holder file and stops its agent-browser daemon over the session's socket;
unarchiving restores none of its ended tabs; at startup, files and daemons of
threads that are no longer live go too. The domain-event stream is a live
tail that can fail, so the adapter resubscribes after a failure.
On v0.1.3 the orchestrator's getShellSnapshot, getThreadShell and
streamDomainEvents keep their signatures, and getShellSnapshot({location:
"active"}) is still unpaged, which the startup sweep relies on. The new
thread.guest-share-updated event is ignored. pingdotgg#21299 now reaps the daemons of
exited Claude, ACP, Pi and Muse agents through their systemd scope, but
upstream still does nothing on archive or delete, for Codex's shared scope,
for terminals, or without systemd, and never touches holder files, so the row
stays whole. liveThread uses Effect.fn and the header comment is cut to the
four-line limit.
On v0.1.4: unchanged; the seam applies cleanly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Where the Environment's shell defines <lazurio-new-tab> and the server keeps the thread's tabs, "+", Mod+T and the empty right panel open Nová karta, a tab that frames the Launchpad's /new-tab, instead of upstream's "+" menu and empty list. A choice turns the tab into a page of the Environment browser, which the thread holds, or opens one of T3 Code's own surfaces through upstream's action. Its tools are upstream's "+" actions without Browser, with the same letters, blocked under any open or closing popup; elsewhere upstream's menu and empty state stay. On v0.1.3 the row merges cleanly: onNewSurfaceKeyDown, the "+" action labels and shortcuts, LAUNCHER_SHORTCUT_BLOCKING_LAYERS and the composer's data-surface-launcher-keys contract are unchanged, and the new Settings modal is a dialog popup, so Nová karta's letters do not fire under it. The header comment is cut to the four-line limit, bare upstream issue numbers are dropped, and the file's three effects (publishing the tools, the element's choice event, the letters' keydown listener) carry justified react-effect-budget suppressions. On v0.1.4: F6 and opening the right panel focus the element marked data-workspace-focus-default (pingdotgg#25877), which upstream's empty panel carries. Nová karta replaces that panel, so it carries the mark and takes focus too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nciliation With T3CODE_LAZURIO_FOLDER a hosted Environment's Chat starts in its Lazurio Folder: decorators over the services orchestration-v2/runtimeLayer.ts builds keep projects, commands and agent sessions in the Folder and offer no Scratch, the startup adopts or creates the Folder's project through ProjectService, and `t3 lazurio model` writes the Platform's recommended model as the Folder project's own override. The web leaves "Add project" and "Copy prompt link" out when every Environment is managed. On v0.1.3 every upstream seam merges cleanly: useHandleNewThread moved into createNewThreadHandler (pingdotgg#25366) and the managedNewThread seam moved with it; runtimeLayer gained GuestShareService and PreviewAgentActivity (pingdotgg#24104, upstream's offline-machine block (pingdotgg#23967) and the overlay's managed-entry block. For the new lint rules (pingdotgg#21514, pingdotgg#25099) the overlay's long comments are cut to four lines, a bare issue number is dropped, and the guard decorators use Effect.fn("LazurioManagedFolder.<op>") like the existing update guard. This also adds lazurioFolder to ServerConfig, which row 6's prompt draft reads. On v0.1.4: Sidebar.tsx keeps upstream's sidebar tree and delegated-thread hooks next to the managed-Folder hook. On v0.1.5 upstream adds "Turn into project" (pingdotgg#26767). runtimeLayer.ts gives ScratchThreadPromotion the guarded project service and guardScratch's project folders, so on a managed Environment promote fails closed (no Scratch root, no Scratch project; covered in managedFolderGuards.test.ts), and the web offers no action because the server sends no scratchWorkspaceRoot. The imports in runtimeLayer.ts and ws.ts keep both sides. Hiding GitActionsControl's git part for the Folder holds with the new showActions (pingdotgg#26904). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Root decision 0200, point 2: inside the app the distribution is "T3 Code (Lazurio)". The build's stage label is "Lazurio", a "Lazurio" label with the approved symbol stands beside the wordmark, previews are not called "Nightly", and the web manifest and index.html carry the name. On v0.1.3 branding.ts, branding.logic.ts and the manifest are unchanged upstream; the document title moved to appInit.tsx (pingdotgg#25004) and still reads APP_DISPLAY_NAME. Upstream's new "failed to start" screen (lib/bootError.ts, pingdotgg#25317, pingdotgg#25345) now names the app with APP_DISPLAY_NAME in its heading and its triage hint; its issue link and the `npx t3 triage` fallback stay upstream's, as decided. bundledDev.test.ts copies branding.ts and branding.logic.ts beside bootError.ts, which now imports them. The badge's comment is cut to the four-line limit. On v0.1.4: unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Root decision 0200, point 4: in the standard look the web client takes the design system's colours, type and radii from the --lz-* tokens the Environment's shell declares (LazurioPlatform F36). One file, apps/web/src/lazurio/theme.css, imported right after index.css in main.tsx; without the shell nothing matches. On v0.1.3 the row applies cleanly. main.tsx now imports the Inter font before index.css, and the theme import still follows index.css directly. index.css (pingdotgg#25323, pingdotgg#25251, pingdotgg#24865 and others) removed no token the file maps; it added guest and diff-icon tokens, which stay T3's. The default "New design" (pingdotgg#24865) maps none of these tokens in light mode; its dark-mode surfaces stay T3's, to be checked on canary for Environment themes with a dark variant. On v0.1.4: upstream's single design (pingdotgg#25778) no longer reads --update-surface, so the mapping is gone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…urns them on Root decision 0201, point 4 (#46): with T3CODE_LAZURIO_FOLDER, Codex and Claude sign in with their own CLIs from the Launchpad's Getting started page (T3CODE_LAZURIO_TOOLS_URL). Where the web offered its own "Continue with ChatGPT" it links to that page, the server refuses T3's own Codex sign-in and profile import for every client, and `t3 lazurio providers` turns the providers on and reads their sign-in again at once. On v0.1.3 ProviderAuthService keeps the same methods, and no new way into Codex's own sign-in appeared. CodexSetupSection.tsx moved its logic into CodexSetupSection.logic.ts (pingdotgg#25524); the only conflict was that import beside the overlay's, and both stay. The guard's start and importProfile overrides use Effect.fn for the new effectFnOpportunity diagnostic (pingdotgg#25099), and the overlay's comments are cut to four lines without bare issue numbers (pingdotgg#21514). On v0.1.4: unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Admin's decision of 2026-10-17: a page without a T3 session asks its own origin for a pairing credential (GET /.lazurio/chat/pairing), which the Launchpad issues with `t3 lazurio pairing` and the operator's scopes (T3's standard client scopes without relay:write), and exchanges it, so the person never sees a token and a deep link keeps its place. On v0.1.3 the row applies cleanly: bootstrapServerAuth keeps its order of credential sources (only comments changed, pingdotgg#21514), and the scope literals, AuthStandardClientScopes and sessionHasLegacyPermissions are identical, so no browser paired on v0.1.2 pairs again. WebSocket tickets now name their route (pingdotgg#24554), which pairing does not touch. The overlay's comments are cut to the four-line limit. On v0.1.4: unchanged. On v0.1.5 upstream's pre-commit hook runs knip (pingdotgg#26167), so OPERATOR_PAIRING_SCOPES and ENVIRONMENT_PAIRING_PATH, which nothing imports, are module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… ceiling Root decision 0210, addendum 3: an agent without a browser (Buddy over SSH, a script) gets an MCP session with the runtime-mode ceiling that only an approved MCP sign-in gives otherwise. `t3 auth session issue --subject mcp-client --runtime-mode-ceiling <mode>` issues it; without the flag such a session stays capped at approval-required. On v0.1.3 issueSession, authenticateMcpClient and issueMcpClientSession keep their shapes; WebSocket tickets gained a route audience (pingdotgg#24554), which does not touch the seam. The only conflict was the comment above MCP_CLIENT_SUBJECT, shortened upstream (pingdotgg#21514): upstream's one-line comment stays, and the constant keeps the overlay's export, which the agent CLI and the release contract use. On v0.1.4: EnvironmentAuth.ts imports upstream's mcpClientScopes from @t3tools/contracts next to RuntimeMode. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…quest, queue and events Root decision 0210, addendum 3: Buddy, and with it every agent in an Environment, works with T3's threads as their owner. It reads and summarizes them, launches, messages, steers and stops them, answers their questions, decides their permission requests and follows their changes, through `t3 thread`, `t3 request`, `t3 queue` and `t3 events`. Each command is a thin client of the running server: T3's own MCP tools where one exists, the person's client surface only where none does. On v0.1.3 upstream merged its thread tools into action tools (pingdotgg#25423). The commands keep their surface, sessions, labels and exit codes; only their MCP calls move: `t3 queue *` calls t3_queue with list, read, edit, cancel, reorder or promote_to_steer, `t3 request respond` calls t3_pending_request with respond, and `t3 thread fork` calls t3_thread_transfer with fork. The tool names are strings the compiler cannot check, so agentCli.test.ts gains a case that drives every queue action and the fork through the real thread toolkit; with the old names it and the respond case fail. Upstream's shell snapshot now takes a query (pingdotgg#24648, pingdotgg#24723) and a WebSocket upgrade names its route (pingdotgg#24554), so the connection passes an empty query and the test's /ws passes "rpc". `send --wait` uses Effect.filterOrElse for the new flatMapConditionalToFilterOrFail diagnostic, and the long header comments are cut to four lines (pingdotgg#21514). On v0.1.4: listItemFromShell takes the caller's scope for each thread's link (pingdotgg#26239, pingdotgg#26642), so t3 events passes this Environment's id and its lines carry the same t3-thread:// link as t3 thread list. mcpClientScopes comes from @t3tools/contracts, and the tests stand in for the linked-environment services and server settings that upstream's orchestrator handlers now need (pingdotgg#17129). The fake t3_thread_launch stamps linked callers as upstream's does. On v0.1.5 upstream's pre-commit hook runs knip (pingdotgg#26167), so requestCommand, queueCommand and eventsCommand, which only agentCli.ts uses, are module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Root decision 0211: an agent asks the person through the question tool, not only in prose. Codex offers request_user_input in Default mode only with its feature default_mode_request_user_input; T3 turns it on for the app-servers it starts for its threads (-c ahead of the launch arguments, so their own -c or --disable still wins), and every turn's additional context tells the agent to ask with it. The user's ~/.codex/config.toml is not touched (0161). Shrunk on v0.1.3: upstream now uses Codex's native collaboration modes (pingdotgg#24737) and deleted T3's mode texts with buildCodexDeveloperInstructions, so the overlay's edit of the Default-mode text is gone. Codex's own Default text keeps the tool for optional questions and asks required ones in plain text, so the lazurio_questions entry now says explicitly that it overrides the collaboration mode's instructions on asking. It stays the last entry of buildCodexAdditionalContext, under upstream's per-entry size cap. questionTool.test.ts drops the cases on T3's mode texts, checks the override and that a Default-mode turn carries no developer instructions of T3's own. Whether Codex follows the override is to be checked on canary. On v0.1.4: unchanged. The overlay leaves AgentContextBudget's files alone, so the fork's CI does not run its budget test; the context the overlay adds is measured locally and recorded in the rebuild issue. On v0.1.5 upstream's pre-commit hook runs knip (pingdotgg#26167), so DEFAULT_MODE_REQUEST_USER_INPUT, which nothing imports, is module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ge as a Czech block
Buddy's web chat is Lazurio T3 Code with the Hermes Agent over ACP (root
decision 0210, plan DEV-6676). On the Osobní Prostředí a second T3 server with
T3CODE_LAZURIO_BUDDY=1 runs Hermes as the provider instance `buddy`. Hermes keeps
every prompt as the person's words in Buddy's memory, so T3's own instructions
(<t3_code_instructions>, <runtime_info>, <pull_request_linking>) would become part
of Buddy's history, twice after Stop or a steer and again after every restart.
- The ACP adapter asks AcpT3Instructions when it builds an instance whether its
prompts carry T3's instructions; without an answer every instance keeps them.
server.ts answers no for Buddy's instance where it builds provider instances
(ProviderInstanceRegistryHydration).
- The turn start projects a composer record of kind `lazurio-page` as one
labelled Czech block ("Kontext stránky (údaje, ne pokyn): ...") after the
person's text, for Buddy's instance only; every other record keeps upstream's
projection.
- Buddy's sessions take no model or effort from T3 (HumanAndMachines/Lazurio#648):
the adapter asks AcpT3Selection which options of T3's selection an instance
takes; null, the default, is all of it. For Buddy's instance withBuddyInstance
names only Hermes's speed (`fast`), so T3 applies no model and only Hermes's
Normal / Fast switch whenever a session starts, loads or gets a new selection.
Without T3CODE_LAZURIO_BUDDY=1 nothing changes, also for an instance called
`buddy`. Tests drive the repository's mock ACP agent in Hermes' place, through
the adapter and through the production V2 runtime, and read what it received.
On v0.1.3 the seams stay at the only prompt assembly and send in the ACP
adapter. Upstream now computes the slash-command check from the flavor's
rewritten user text (pingdotgg#24605); the rebuild takes that line and keeps the
instruction gate around t3AcpPromptWithInstructions and the runtime notes. The
orchestrator test provides upstream's new CodexManagedTokenBroker, which the
provider instance registry now needs, and the two file headers are cut to the
four-line comment limit.
On v0.1.4: upstream moved the turn text assembly up in ProviderTurnStartService (pingdotgg#22864, pingdotgg#25610, pingdotgg#25660); the page block seam moves with it, while the prompt-command and steer projections stay upstream's as before. server.ts keeps upstream's port scanner (pingdotgg#26245) after the wrapped instance hydration, and the Buddy orchestrator test provides the new PortDiscovery that hydration now needs. The pingdotgg#648 selection gate, which row 28's commit carried on v0.1.3, comes back to this row and sits beside upstream's flavor hook (pingdotgg#24605).
On v0.1.5 upstream makes the client file system's writeTextFile optional
in the ACP adapter (pingdotgg#26876), away from the overlay's blocks. Upstream's
pre-commit hook runs knip (pingdotgg#26167), so LAZURIO_PAGE_CONTEXT_KIND,
buddyT3Instructions, LAZURIO_BUDDY_ENV and isBuddySurface, which nothing
imports, are module-private.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ds Buddy's thread budíček wakes Buddy with a message into Buddy's T3 thread (root decision 0210, plan DEV-6676) and sends it again after a crash. It needs the send to happen once per wake, to know which thread is Buddy's, and to tell a final refusal from one worth retrying. - `t3 thread send --idempotency-key <key>` passes T3 a SHA-256 digest of the key with the thread and the sender (T3CODE_ACTING_SENDER and T3CODE_ACTING_FOR of the "Buddy za …" trace) as the MCP tool's clientRequestId. T3 derives the command and message ids from it within the MCP client's request namespace. A decorator where server.ts provides the MCP client authenticator puts the agent commands' sessions (label "t3 agent cli") in one namespace, so the same key names the same command across commands, sessions and restarts, and T3's command receipt runs it once. Every other MCP client keeps upstream's namespace. - After a keyed send the command reads what became of it through POST /api/lazurio/agent-cli/send-state (orchestration:read): T3's receipt of the key's command and the message it made. A repeat prints the first send's result with its commandId; the same key with another message fails with `idempotency_conflict` and sends nothing; a key T3 rejected fails with `command_rejected` and stays rejected; a repeat T3 cannot replay because it checks the thread first (archived since) prints `"delivery": "delivered"` with the message's id, run and commandId. The conflict check compares the trimmed text, as T3's tool trims the message it decodes. Other failures keep their codes and are worth sending again with the same key. - `POST /api/lazurio/buddy/thread` finds or makes Buddy's one thread: thread `buddy` on the instance `buddy` in Buddy's project (~/Lazurio/.agents/buddy), made by a fixed command so two first asks make one thread, and brought back if it was archived. A thread `buddy` in another project or on another instance is never taken: the route answers 409 `thread-conflict`. 404 outside Buddy's T3 Code, 409 without Buddy's project. `t3 lazurio buddy thread --json` asks it as an agent command. - `t3 lazurio capabilities` says so with "threadSendIdempotency", "threadSendOutcome" and "buddyThread". The "budíček" label on the message is a claim of the "Buddy za ..." trace and not part of this change. The end-to-end test runs separate `t3 thread send` commands against T3's own MCP tool over the production runtime; with the raw key, without the shared namespace, or without the conflict, rejection or delivered branches, it fails. On v0.1.3 the key keeps its place in row 21's `send`: the key is evaluated first, then the message is sent through `t3_thread_send`, and `--wait` waits only on the run of that send or of the receipt T3 replays. That replaces the rebuilt row 21's `Effect.filterOrElse` around the send. Command ids still come from the MCP client's request namespace and the key (stableCommandId is unchanged), and `t3_thread_send`'s new `link` field (pingdotgg#24784) is ignored by the result schema. The namespace decorator's `authenticate` is an `Effect.fn`, as upstream's McpOAuth.authenticate now is (pingdotgg#25099, effectFnOpportunity is an error), the Buddy test runtime provides upstream's new CodexManagedTokenBroker, and the file headers are cut to the four-line comment limit. On v0.1.4: upstream gives every outside MCP client a web origin for its thread links (pingdotgg#26642); the agent commands' sessions drop it in agentCliRequestScope, so their links stay t3-thread:// links T3 Code's chat opens, as on v0.1.3, and the namespace test asserts both sides. The Buddy test runtime wraps provider hydration with withBuddyInstance as server.ts does (row 23) and provides upstream's new PortDiscovery, and the agent CLI tests provide RemoteDelegation, the peer services and the server settings T3's thread tools now need. On v0.1.5 upstream's pre-commit hook runs knip (pingdotgg#26167), so agentCliRequestScope, which nothing imports, is module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… the bubble Root decision 0210, plan DEV-6676 (row 25). With T3CODE_LAZURIO_BUDDY=1 the web client is Buddy's surface: a header with Mattyčus, the conversation's days in a pane where the window has room and a date line above each day's first message, and no thread list, new thread, fork, rollback or thread details card. `/` opens Buddy's one thread through the thread route, and a message sent during a turn steers it; queueing is the explicit alternative. In Buddy's bubble the surface speaks the frame's side of lazurio.buddy.* v1, written from the protocol's description: it says it is ready, keeps the last valid page context from its parent on the host's exact origin, and asks for its window's size from its header and on Escape, which asks for the panel unless a dialog, menu or list is open in the surface or something inside stopped the key (the editor marks every Escape as handled). A day in the pane turns off following the end first, as the timeline's minimap does, so the jump stays. In the bubble the surface wears the host page's appearance through T3's own appearance preference; where T3 cannot wear it (storage blocked, or a saved single-appearance theme), the document wears T3's standard palette in the host's appearance (request of 2026-10-25). The server holds the same for every client and agent. Decorators where it builds the orchestrator and the checkpoint store refuse forks, rollbacks, other threads and deleting Buddy's thread, and take no checkpoints in Buddy's project, which is the managed Folder's (T3CODE_LAZURIO_FOLDER=<Folder>/.agents/buddy) and else ~/Lazurio/.agents/buddy. A thread.create with Buddy's thread id passes only while Buddy's thread route makes the thread (MakingBuddysThread), so a client cannot spend the route's fixed command on a thread of its own. A startup phase before recovery turns off continuing threads after an update, the agent browser, and Codex and Claude, once, recorded in <state>/lazurio/buddy-surface.json so that later choices stay. `GET /api/lazurio/buddy/days` lists the conversation's days for the pane. The day lines and the day jump check Buddy mode once per timeline, for the timeline's own Environment, and the rows read it from the timeline's shared state, so no other Environment's timeline does that work or takes a jump. On v0.1.3 two web seams are rebuilt and one server refusal is added. - Upstream installs the chat route's shortcuts once at app start (pingdotgg#25366 removed ChatRouteGlobalShortcuts), so Buddy's condition joins their `when` in shortcuts/chatRouteCommands.ts: `isBuddySurfaceNow()` reads the primary server config from the app's atom registry when a key is pressed. Without it Shift+Mod+N on Buddy's surface would try a new thread that the server then refuses. - The timeline no longer takes onManualNavigation (pingdotgg#25463); the day jump is called below the timeline's own navigateTimeline and passes it, and the day line sits beside upstream's AudioPreviewUnmountContext (pingdotgg#21363). - Upstream's guest share of a thread (pingdotgg#24104) is refused in Buddy's T3 Code: thread.guest-share.open, .redeem and thread.guest-message.submit fail in the command guard, because Buddy's conversation belongs to a Personalspace, which is never shared (root decision 0091); closing a share stays possible. The root renders no GuestShareDialogHost on Buddy's surface. A test drives a guest share of Buddy's thread through the server's orchestrator. Settings and Usage are modals over the thread now (pingdotgg#24847); the prompt-link draft stays off Buddy's surface inside the rewritten ChatRouteLayout, and the first-run gate stays off on NEW's slimmer root. The guards are Effect.fn decorators (effectFnOpportunity), the two effects of BuddySurface.tsx carry justified react-effect-budget suppressions, and the file headers are cut to the four-line comment limit. Any other thread of Buddy's Environment, opened by a link or a typed address, leads to Buddy's thread as `/` does: the chat layout shows BuddySurfaceIndex, which asks the server for Buddy's thread and replaces the address, so that thread never renders under Buddy's presentation. A thread of another Environment stays T3's, and ChatView and the thread details ask about the thread's own Environment. A browser test opens such an address directly. On v0.1.4: the root keeps upstream's local-Environment switch beside the Buddy surface check (pingdotgg#26207); the timeline finds upstream's unmatched pending approvals (pingdotgg#26255) after the day lines and adds the day keys to upstream's list data next to its new footer. ThreadDetailsPanel no longer exports its props type (pingdotgg#26238), so Buddy's panel takes ComponentProps of it, and the effect suppressions use the renamed lint rule t3code/no-unreasoned-state-sync (pingdotgg#26161). The host appearance, which row 28's commit carried on v0.1.3, comes back to this row: T3 no longer re-applies its theme from useTheme's effect (pingdotgg#25007, pingdotgg#25461), so the stand-in follows every application of T3's saved theme through subscribeRenderedAppearance, and the theme tests apply T3's stored appearance as app start does. On v0.1.5 the imports in runtimeLayer.ts and ws.ts sit next to ScratchThreadPromotion (pingdotgg#26767). Upstream's pre-commit hook runs knip (pingdotgg#26167), so BUDDY_DAYS_ROUTE, withBuddyDefaults and buddySurfaceProtocol.ts's constants and helpers that only that file uses are module-private. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…son can remove Root decision 0210, plan DEV-6676 (row 26). Buddy's surface shows the host page's last valid lazurio.buddy.context as a chip above the composer, for example "Apps /apps", with a button that removes it. While the chip is there, a message the person writes carries the page as a composer record of kind `lazurio-page` with a reference in its text. Buddy's T3 Code projects it for Hermes as the labelled Czech block of row 23. An empty message carries nothing. A removed chip stays removed for its page, also after the host visits another page and comes back; another page brings its own chip. The page hook takes the chat's Environment (useBuddyPage(environmentId)), so a thread of another Environment never carries Buddy's page record. The record is the contracts' generic UnknownContextRecord with the payload buddyPrompt.ts reads, so no contract changes. The reference joins only the regular send's text, and that send's context takes the record from that same text; the queued-message edit and the plan follow-up carry no page, and the chip is hidden while a queued message is edited. The person's words stay T3's messageTextForSend, and the page joins a text of its own, pageTextForSend, which only the record and the texts on the wire read: a failed send, single or multi-model, gives the composer back the words, and the retry carries the page the chip shows then, or none. The composer's and the sent message's presentation registries show a page reference as a page chip in their fallback, where T3 would call an unknown context unavailable. buddySurfacePage.test.ts covers the record, its id, its label, the wire schema and the empty message. On v0.1.3 the row applies as it is. The send's snapshot still keeps messageTextForSend as the person's words (pingdotgg#25710 touched the optimistic message path, not the snapshot), and upstream's new approval-feedback send (pingdotgg#23657) sends the person's words without the page, which suits approvals that Buddy with full access rarely asks for. The chip stays above ChatComposer after the queue moved to the timeline's end (pingdotgg#25401). Only ChatView's imports conflicted, beside upstream's new canvas and preview-source imports, and the record's file header is cut to the four-line comment limit. On v0.1.4: the message context also carries upstream's linked Environment contexts (pingdotgg#17130) inside the page record wrapper, and the context presentation keeps upstream's linked Environments import beside the page chip. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…r decided a request
Root decision 0210, evening addendum, point 5 (plan DEV-6676, row 27): what
Buddy writes or decides in a thread carries the visible mark „Buddy za <user>“
("Buddy for <user>"). Delegace's wake in Buddy's own thread is not shown at all,
as on Telegram (decided 2026-10-22), so the person sees only Buddy's reply.
Who a session acts as is a claim signed into its token beside the runtime-mode
ceiling (`act`), from a closed set of kinds: buddy with the user's name, or
delegace; budicek is no alias. The agent commands issue their sessions with it
when T3CODE_ACTING_SENDER (with T3CODE_ACTING_FOR and
T3CODE_ACTING_FOR_ACCUSATIVE) names one, and refuse any other value before they
read anything. The server reads it from the session alone: an MCP client's
invocation carries it, the client surface runs a dispatch as its session, and a
decorator of the orchestrator records the message or the request's resolution
in a file per thread in the T3 home, only when its own dispatch committed that
step. A replayed command id, an overlapping dispatch of the same id or a retry
takes no one else's step, and a step's first record stands. The web reads
/api/lazurio/acting-senders. The thread's rows leave out Delegace's wake and
hold an agent's message from outside the thread until the answer covers it,
five seconds at most; a server without the route, or an error, shows the thread
at once as upstream does. Buddy's message and a request Buddy decided show
„Buddy za …“. The person's own steps, T3's messages, automations and other
threads' agents get no mark and never wait. Tests: rejections before
successes, the real CLI against /mcp and the client surface through to the
route the web reads, replays on upstream's own orchestrator, the claim in the
token, and the web's label, parse and loader.
On v0.1.3 three small conflicts are resolved by intent. Upstream computes the
folded agent message's sender label once (pingdotgg#24104) and also reads it out in
the accessible heading (pingdotgg#23780); the overlay wraps that senderLabel in
LazurioActingSenderLabel on the visible fold, which is the one place the
mark goes. McpOAuth's authenticate is upstream's Effect.fn now (pingdotgg#25099), and
the client gets the one actingSender spread line there. EnvironmentAuth keeps
row 20's MCP_CLIENT_SUBJECT export. Upstream's guest attribution (pingdotgg#24104)
is a message-context record of its own and does not mark who acted for a
person, so the overlay's session claim stays. The orchestrator decorator's
dispatch is an Effect.fn (effectFnOpportunity), the two effects that ask
the server's record carry justified react-effect-budget suppressions, the
agent CLI test keeps row 21's queue and fork case beside this row's cases,
and long comments are cut to the four-line limit.
Buddy's day pane counts the messages the timeline shows: the server's day list
(buddySurfaceDays.ts) leaves out Delegace's wake and an agent's message the
record has not answered yet, by the predicate in actingSenderVisibility.ts,
which the server and the web hold as one identical file that the release
contract test keeps equal. A day that opens with a wake jumps to the person's
first message, and a day of wakes alone is not listed.
On v0.1.4: the acting sender sits beside upstream's peer link (pingdotgg#16695) in the session, its signed claims, the MCP client and its caller, next to upstream's narrowed modes and web origin (pingdotgg#16653, pingdotgg#26642); the test takes mcpClientScopes from contracts, where upstream moved it.
On v0.1.5 upstream's pre-commit hook runs knip (pingdotgg#26167), so
ACTING_SENDER_NAME_MAX_LENGTH, ClientSurfaceActingSender,
actingSenders.ts's make and ACTING_SENDERS_ROUTE, which nothing imports,
are module-private. actingSenderVisibility.ts must stay the same file on
the server and in the web, and each side uses part of it, so its
functions keep their exports and are @public to knip.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Root decision 0210, addendum of 2026-10-22, point 1, and its plain-chat addendum (HumanAndMachines/Lazurio#648; plan DEV-6676, row 28): the person sees and hears only what Buddy writes in human words. In Buddy's surface (lazurioBuddy) only: - The timeline keeps the messages and what the person acts on; T3's record of the work stays out. While a turn runs, or work still runs after it, one quiet static line says "Buddy na tom pracuje…" / "Buddy is on it…". A failed turn shows one human line, and the thread's error banner says "Něco se nepovedlo. Zkuste to prosím znovu." instead of T3's text. - None of the turn's work shows at the end of the timeline, and Buddy's queue holds and counts only the person's own messages, never an agent's such as Delegace's wake. - The composer is a message box ("Napište Buddymu…") whose only choice is Hermes's Normal / Fast switch, the one option row 23's AcpT3Selection lets through, and Buddy's thread keeps full access, which the server guard also holds. - The surface never shows T3's terminal or right panel, their keys stay the browser's, and a link in the conversation opens in a new browser tab. The terminal and right-panel states are read inside the store selectors, so the React Compiler keeps ChatView's panel presence values memoized (chatViewPanelPresence.test.ts guards it, #134). On v0.1.3 upstream moved the work banners and the queue to the end of the timeline and removed the composer's task list (pingdotgg#25401). The work items (childInputNow, goalNow, backgroundWorkNow) are masked on Buddy's surface with inline conditionals in ChatView's body, where hasThreadNow, ThreadNow and the scroll button's summary read them, so no plain function wraps a hook result in render. buddyBackgroundWork is whether backgroundWorkNow exists. useBuddyQueuedRunCount drops an agent's queued message from the footer's count, which upstream's getUserQueuedThreadRuns keeps, and buddyWorkBanners and the task-list seam are gone. useBuddyChatShortcuts takes upstream's `!backgroundThread` condition (pingdotgg#24847), ChatTerminalDrawers lost focusRequestId (pingdotgg#25009), the placeholder falls back to DEFAULT_COMPOSER_PLACEHOLDER, and ReopenClosedViewShortcut stays off on the slimmer root. Effects carry justified react-effect-budget suppressions and comments are cut to the four-line limit. The error banner asks about the thread's own Environment (ChatBannerLane passes it), so a thread of another Environment keeps T3's own text. On v0.1.4: upstream dropped the resting composer's control strip, so Buddy's composer hook only gives the placeholder and hasControls is gone; Buddy's controls still replace T3's in ComposerControlsBar ahead of upstream's controls ownership. The timeline mask keeps upstream's pending approvals footer, which reads the final rows. useChatShortcuts no longer exports its input type, so the overlay takes it from the hook. The tests follow upstream's props and labels: no activeTurnInProgress or onRollbackCheckpoint, the queue's "1 queued message", background work rows with turn items and "Running …" / "Waiting on …" titles, and a single subagent as a [data-v2-item-type=subagent] row. Effect suppressions use the renamed no-unreasoned-state-sync rule. Row 23's AcpT3Selection, row 25's host appearance and row 7's launcher clearance, which this commit carried on v0.1.3, are back in their rows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From v0.1.3 a follow-up steers the running turn by default (pingdotgg#24718). A steer into a turn that waits on a pending runtime request aborts the provider's pending callback: Claude steers with priority "now", a pending AskUserQuestion resolves as cancelled and an approval as cancel, and the person never sees the question (#139). #119 guarded only sendToThread's auto mode; the composer's explicit steer, the auto branch of the delivery intent and promoting a queued message still steered through it. The guard now lives in one place, CommandPolicy.resolveMessageDispatchIntent: while the thread has a pending runtime request, any steer_active becomes queue_after_active. It covers a steer requested as a delivery intent (auto or steer) and one requested as a dispatch mode (sendToThread, older clients). The orchestrator reads the thread with its runtime requests on every message.dispatch, so no caller has to load them. Promoting a queued message to a steer checks the same predicate (waitsOnPendingRequest) and puts the message first in the queue instead, so it runs right after the answer. Restart is unchanged. sendToThread's own check from #119 is gone, and ThreadManagementService.ts is upstream's again; its test resolves the dispatched mode through the guard, and an explicit steer with a pending request now queues too. The allowlist trades ThreadManagementService.ts for CommandPolicy.ts, Orchestrator.ts and their tests, and the user guides for the composer and the agent CLI say a steer queues while a question waits. On v0.1.4: upstream renamed stopRunForGoalCommand to stopRunForQueuedCommand with a required reason (pingdotgg#25837); the guard passes 'Queued behind a pending request' and stays after the compaction and /goal branches. pingdotgg#25846 renamed the queued message action to Send now, and composer.md names it. On v0.1.5 pingdotgg#26715 queues a steer for a provider that can neither steer its running turn nor restart it. The overlay's pending-request check runs before that branch and still holds; the row's ThreadManagementService test gives its projection empty providerThreads and providerSessions, which the new branch reads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ion closes Effect RPC interrupts every fiber of a client whose socket closes. The git stacked action ran in its stream's fiber, so a dropped connection stopped it halfway: a commit without its push, a push without its pull request. It now runs detached from the socket, the same pattern upstream pingdotgg#18980 gave the server update, and the pull request link and git status refresh still run after it. The client reports a lost transport as a lost connection rather than a failed action; the result shows through the git status and thread pull request link it already resyncs. Row 31 of the patch stack (#125): allowlisted in lazurio-fork-ci.yml and listed in the release runbook. On v0.1.3 the row applies as it is: the gitRunStackedAction handler still runs gitWorkflow.runStackedAction inside the RPC stream's fiber (it moved within ws.ts), effect is still 4.0.5, and upstream's only detached progress stream is still the self-update one. The allowlist entry and the runbook note go to the distribution row. On v0.1.4: replays unchanged; pingdotgg#21046 publishes local git status before the remote lookup and does not touch the detached progress stream. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…3 line Up to v0.1.2 the default follow-up was queue, and the web client saved it with the whole settings object, so most people hold followUpBehavior "queue" without having chosen it. On 2026-10-28 the Organization Admin decided that everyone moves to steer once on the first update to the v0.1.3 line; who wants queue sets it again in Settings (#140). The steer guard from #139 keeps a steer from cancelling a pending question. The web client's one read of its settings (readBrowserClientSettings, key t3code:client-settings:v1) runs a migration from apps/web/src/lazurio/: a saved "queue" without the marker becomes "steer" and is written back with the marker lazurioFollowUpSteer: true. Every write on the line stores the marker next to the settings, so a queue chosen afterwards sticks. A fresh client has no saved settings and keeps the default steer. The marker lives only in this storage schema; ClientSettings and the contracts do not change. Desktop and mobile are left alone. Both are the official upstream apps, which this fork does not build or ship: desktop keeps its client settings in its own file through desktopBridge, and mobile in its own preferences. On v0.1.4: replays unchanged; the default follow-up is still steer. The CI allowlist lines go to row 5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ad of cancelling it
A message sent while an ACP agent works is steered by cancelling the
running turn (session/cancel) and sending the message as the next
prompt, because ACP has no steering request. For Buddy (Lazurio Hermes
over ACP) every such message stopped his work and he started it again.
An agent that lists "lazurio.activeSteer": 1 in its initialize
capabilities' _meta now gets supportsActiveSteering for its session, and
steerTurn sends the extension request _lazurio/steer {sessionId, text}
with the message's text and its attachments as saved paths. The turn
goes on. An answer other than steered waits up to 10 s for the prompt
to settle and fails: a turn that ended leaves the message to the next
turn; a prompt the agent has not started yet is steered by the effect's
retry. Agents without the meta keep steering by interrupt and restart.
effect-acp's initialize normalization now keeps capabilities._meta.
Tests: the mock ACP agent advertises the meta under
T3_ACP_LAZURIO_ACTIVE_STEER=1 and answers _lazurio/steer. The adapter
test steers a running turn, which completes with the steer's text and
without session/cancel, and a steer after the turn fails. A second test
keeps restart steering for an agent without the meta.
Claude Opus 5.5 in Claude Code (T3 Code).
The row also carries the two review rounds of #141: a steer names its turn and message, so it reaches only that turn and only once, and a steered message becomes the next turn only when the agent refused it.
On v0.1.4: pingdotgg#25610 added commitReplacementSession for a session that replaces the running one (handoff recovery, rollback). It now reads the replacement's _lazurio/steer capability too, so a replaced session does not keep the old session's answer to whether the agent steers.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The distribution's files on the new base, upstream T3 Code v0.1.5 (6d450a4), last in the stack: CI, the CLI archive, release and upstream watch workflows, the image, the issue form, README, SECURITY.md, the runbook, the overlay spec, the contract test and the rebuild's skill. They are main's files, made current for v0.1.5 (#148). On v0.1.5: - CI and the contract test pin v0.1.5 and build 0.1.5-lazurio.0; the issue form's version example is 0.1.5-lazurio.1. Node 26.12.1 and pnpm 12.14.0 are unchanged, so the toolchain pins hold. SECURITY.md's upstream section equals the new tag's policy. - The Linux CLI archive now ships lib/libatomic.so.1 and patchelf sets t3's RUNPATH to it (pingdotgg#26912, pingdotgg#26932), so lazurio-cli-archives.yml installs patchelf before the build, the way upstream's release-desktop.yml does; the contract test pins the order. - useUpdateEverything.ts leaves the allowlist: row 4 now keeps a server's advertised release out of waitForNpm in updateEverything.logic.ts (pingdotgg#26917), and the contract test pins that seam there. The fixed test gate is unchanged. - The contract test's pairing pins follow the constants that knip made module-private (upstream's pre-commit hook runs knip:check since pingdotgg#26167). - The runbook's Overlay table describes every row on v0.1.5, the Cílový stack names each row's new commit, the swap step names the workflows to disable after the swap from the v0.1.3 base (agent-context-budget.yml, mobile-fingerprint-label.yml; v0.1.5 adds none), and stage 3 and the skill say to replay with --no-verify and run knip over the finished stack. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 of 9 tasks
Author
|
Dozor: please request a review from Pablo (
This PR is not to be swapped onto — T3 Release (bot) |
4 of 9 tasks
Author
|
Supervisor: the state for the real v0.1.5 rebuild.
— supervisor of T3 Release |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Status: draft, waiting for a review on the exact head
be4df21b7c. Fork CI on that head is green: 41021193469, all four required checkssuccess. This is the real rebuild (stages 2–9 ofdocs/operations/lazurio-fork-release.md). It is never merged by its button: its head becomesmainthrough the swap in stage 6. The swap waits until stable0.1.3-lazurio.1captures the oldmain.Rebuild issue: #148 (inventory and every row's decision).
Inputs
v0.1.3=d2c440312e5f39d59827ed466838a623516454d6(main's base)v0.1.5=6d450a4284852af137b2f3407fddd89eb76e7644(tagupstream-v0.1.5)lazurio/rebuild-v0.1.4at1252de8e30fec82765f4b130a0a3b99cc0b1df6f(#144, the dry run on v0.1.4)expected_old_main409b1b09c322746b5972343f640f9d7357cc76e9candidate_headbe4df21b7c941b19f443de6b393adc33f28d6729What the rebuild does
The overlay from #144 is replayed onto v0.1.5 as one commit per row, in the target stack's order, with row 5 (distribution) last: 31 commits. Every row changed by v0.1.5 has an "On v0.1.5 …" paragraph in its commit message. Row 33 (ACP steer, #138) is in its own row, as on v0.1.4. The trial replay applied 27 commits cleanly; rows 4, 10, 15 and 5 needed work.
Rebuilt rows:
collectServerUpdateTargetsreturns them aswaitForNpm, decided byreleaseArchivesPublished, which the web derives from the desktop's channel and which is alwaysfalsein a Lazurio web client. Lazurio's-lazurioreleases are not on npm, so without a change every server would wait forever. The overlay leaves a target fromadvertisedServerUpdateVersionoff that list inupdateEverything.logic.ts, anduseUpdateEverything.tsis upstream's again.serverUpdateOffer.test.tscovers it. The Stable/Nightly switch (feat(updates): switch your whole fleet between Stable and Nightly in one step pingdotgg/t3code#26288) stays upstream's: a Lazurio web client hides it, and the server's check does not treat Lazurio's channels as a track switch.docs/user/updating.mdsays the distribution publishes no Nightly, so a desktop's switch to Nightly fails for a Lazurio server when it downloads the release, and the server keeps the release it runs (decision A in Přestavba na upstream T3 Code v0.1.5 #148).ServerEnvironment.tskeeps both sides' imports and upstream'sdesktopAppUpdateanddesktopAppChannelSwitch;serverBrowseris still left out only on a Lazurio Environment. The automatic resolution droppeddesktopAppChannelSwitch; it is back.runtimeLayer.tsgivesScratchThreadPromotionthe guarded project service andguardScratch's folders, so on a managed Environmentpromotefails closed, and the web offers no action because the server sends noscratchWorkspaceRoot. A new test inmanagedFolderGuards.test.tschecks that a promotion under the managed Folder fails with "Only a No project thread with its own folder can become a project." and dispatches nothing (decision B in Přestavba na upstream T3 Code v0.1.5 #148). HidingGitActionsControl's git part for the Folder holds with the newshowActions(feat(web): choose what the thread details card shows pingdotgg/t3code#26904).ThreadManagementServicetest gives its projection emptyproviderThreadsandproviderSessions, which the new branch reads.knip in the pre-commit hook. Since pingdotgg#26167 upstream's staged hook runs
knip:checkover the repository. Exports of the overlay that nothing imports are now module-private in their rows: rows 10, 11, 19, 21, 22, 23, 24, 25 and 27.actingSenderVisibility.tsmust stay the same file on the server and in the web, and each side uses part of it, so its functions keep their exports and are@publicto knip. The replay runs with--no-verify, and knip runs over the finished stack. Lazurio Fork CI does not run knip; it is a local gate (decision E in #148).Distribution (row 5)
0.1.5-lazurio.0; the issue form's example is0.1.5-lazurio.1. Node 26.12.1 and pnpm 12.14.0 are unchanged.lib/libatomic.so.1, andpatchelfsetst3'sRUNPATHto it (fix(cli): t3 starts on a fresh Ubuntu server without libatomic pingdotgg/t3code#26912, fix(release): Linux CLI archives build on runners without package docs pingdotgg/t3code#26932).lazurio-cli-archives.ymlinstallspatchelfbefore the build, as upstream'srelease-desktop.ymldoes, and the contract test pins the order.useUpdateEverything.tsleaves it; the contract test pins row 4's seam inupdateEverything.logic.ts. The fixed test gate is unchanged.agent-context-budget.ymlandmobile-fingerprint-label.yml(from v0.1.4; v0.1.5 adds none). Stage 3 and the skill say to replay with--no-verifyand run knip over the finished stack.release.ymlstays disabled in the fork (decision D in Přestavba na upstream T3 Code v0.1.5 #148).What stays the same (stage 5)
main's v0.1.3 the upgrade adds migrations 070–072, which only add.projectsCreateFromThread, usesAuthOrchestrationOperateScope; scopes and the default pairing grant are unchanged. On a managed Environment it fails closed (row 15).t3 lazurio capabilities,modelandprovidersare unchanged.pnpm-workspace.yaml.Verified locally on
be4df21b7cnode --test scripts/lazurio-release-contract.test.mjs: 49/49.vp fmt --checkandvp lint --report-unused-disable-directivesover the repository: clean (two warnings in upstream'smarkdownWindowsPaths.ts).vp run knip:check: clean.managedFolderGuards.test.tsandThreadManagementService.test.ts: 29/29.On an earlier head of this branch, with the same code except the new test's mock type and docs, the overlay's tests were green:
CommandPolicy,SteeringCompletion,AcpAdapterV2, cloud, config, ws, lazurio): 591 passed;Open
mainis in progress. This stack is built from Rebuild the Lazurio overlay on upstream T3 Code v0.1.4 #144's head, so any finding there also goes into the matching row here as a fixup.Read the overlay locally rather than in GitHub's diff, which also shows every upstream change between the bases:
Done with Claude Code (Claude Opus 5.5) as the T3 Release bot.
🤖 Generated with Claude Code