Skip to content

Upstream integration cycle: 921cb3c8bc..99e08526e5 (30 sources) #981

Closed

Description

@rynfar

Successor to #967. Frozen T3 range: 921cb3c8bc772309ccab4c422b091d0a91497a49..99e08526e5ec84f294940cba5929841518c52fec (30 source commits), fetched on 2026-10-02 against Pylon 00884406f7. Commits that arrive in T3 later belong to the next cycle. The standing approval and constraints are the same as #865/#961/#967.

Initial triage (not final until a PR lands or a skip is recorded):

Group Sources Initial triage
A. Small web fixes 71a90ae70e hotkey recorder, ced865c224 PR checks icon, fa6262db31 restart advice, 20012ebd80 terminal toggle spacing, 67f640093f Docker icon, 5a574a77d1 duplicate sidebar tests Port.
B. Desktop preview fixes 5cc99e1c23 no Save dialogs from agent clicks, 3e60fecf39 dark-mode markdown pages Port.
C. Cloned project favicons 6ea01f8d24 Port (server, client-runtime, web, mobile).
D. GitHub polling via batched GraphQL 10ac2f2ba4 Port with care. Check Pylon's Forgejo/Bitbucket providers and PR sync reactors.
E. Mobile fixes without SDK 58 99e08526e5 unused debug helpers, 9962e6986d iOS scene display scale, 09388bf2da stale Live Activity, 438af295fe + bed69f6ea4 notification stacking and per-thread Android suppression (Pylon relay) Port where independent of SDK 58. Needs a native build to ship.
F. Expo SDK 58 / RN 0.88 RC series 8dc07f199c, 1e9c36023c, e41755cf8a, ce920f2ac8 Likely defer: RN 0.88 is a release candidate, and this is a native upgrade that needs release coordination.
G. Product decisions 148e6deea0 new project from a name, b33eda1399 beta Working section, 0a04cc50de one-click provider updates on every machine, 39405f1992 mobile "No project" row (tied to #963) Maintainer decision; compare with existing Pylon behavior.
H. Skip / covered 41a8239849 CLI smoke (EXC-2), b91e4668fa / a97a4a9d18 T3 marketing, a3fb5392e3 / 094fb230e9 T3 docs, 2731929610 Tiptap undo (EXC-6; Pylon is still Lexical), a3abb52660 eas-cli pin (already covered: Pylon pins below eas-cli 22) Skip or covered.

Workflow: review-t3-upstream skill, isolated worktrees from fresh origin/pylon, focused regression tests, an independent adversarial review, final-head CI. Advance .agents/upstream-review.md only when every source has an authorized outcome.

Activity

  1. rynfar commented on Oct 2, 2026

    @rynfar
    CollaboratorAuthor

    Design review

    Design review: start a new project from just a name

    Reviewed upstream 148e6deea046658639aae9fef5b349781cec39d1 (#14527) against Pylon 00884406f7d8c59c3ee98a617ba8a1eb64661a04.

    Upstream behavior

    apps/server/src/project/NewProject.ts introduces an Effect folder-creation operation. It claims <server baseDir>/projects/<slug>, suffixing occupied names through 100 attempts, initializes Git, writes README.md and assets/icon.svg, stages those files, and attempts an initial commit. It respects init.defaultBranch, otherwise using main.

    Initialization/file failures remove the claimed folder. Commit failures preserve it and return a warning, allowing the project to open without a commit.

    apps/server/src/ws.ts calls the operation, then dispatches the existing project.create. Typed dispatch failure removes the folder; interruption retains it because creation may already have entered the command queue.

    Contracts add projects.createNew, operate-scope authorization, a name limited to 200 characters, a result containing projectId, workspaceRoot, and optional commitError, and optional ServerConfig.newProjectsRoot. No migration or new orchestration event is included.

    packages/shared/src/path.ts supplies normalized, bounded folder names, including Windows device-name handling. Shared client helpers preview paths and derive GitHub publishing targets.

    Web/desktop add a command-palette name step and hooks/useNewProject.ts. Mobile adds AddProjectNewRoute.tsx, a Stack route, and AddProjectNewScreen within features/projects/AddProjectScreen.tsx. Both wait for the projected project before opening a draft and optionally publish a private GitHub repository using the selected environment’s credentials.

    Current Pylon behavior

    Pylon already adds folders through CommandPalette.tsx, projectEnvironment.create, and orchestration/Normalizer.ts; web can request creation of a missing workspace root. Mobile’s AddProjectScreen.tsx browses folders, detects existing projects, and dispatches project creation.

    Existing clone flows are more substantial: ProjectCloneTracker.ts, web clone coordinators, and mobile destination screens provide environment-scoped progress, cancellation, retry, and older-server fallback.

    Name-only creation adds Git initialization and starter content, so it is not fully covered by existing add-project behavior. However, its navigation, environment selection, and recovery should reuse Pylon’s flows rather than establish a competing project implementation.

    Upstream’s generated README advertises T3 Code. That must be adapted to Pylon. The storage root must derive from Pylon’s configured runtime identity, not a hard-coded upstream home.

    Options

    • Don’t adopt. Preserve add-folder and clone flows across web, desktop, and mobile. No contracts, migrations, decider/projection, remote/tunnel, or provider changes. Low risk and negligible size; users initialize a repository themselves or ask an agent in Scratch.
    • Adapt the name-only flow. Add the optional RPC/config contracts and integrate “New project” into existing add-project navigation. Keep existing project events/projections; no schema migration is inherently necessary. Use a server-owned creation service with stable operation identity and explicit cleanup boundaries. Every client targets the chosen environment; publishing uses that environment’s account. Prime and other providers receive a normal project after creation. Medium risk; roughly 1–2 engineering weeks.
    • Generalize project provisioning. Model new, clone, and eventual Scratch promotion as durable provisioning intents handled by queue-backed reactors. Project status and operation outcomes become projected contracts shared by all clients. New events/projections may require a migration after Pylon’s current 67. Remote routing and provider admission remain environment-owned. Higher risk and roughly 3–4 weeks; worthwhile only if broader provisioning is intended.

    Recommendation

    Adapt the feature, but let the maintainer choose its relationship to existing add-project flows. Retain folder import and clone behavior, and distinguish “New project” from “Add existing project.”

    Resolve three product questions: whether new repositories belong under runtime data or the configured add-project base directory; whether starter files and attribution are wanted; and whether optional GitHub publishing belongs in the first release.

    The name-only RPC lacks client-supplied idempotency identity. A lost successful response followed by retry can create a suffixed duplicate. Fix that before adoption. Also test interruption between folder creation and project dispatch, and ensure cleanup only follows a proven uncommitted rejection.

    With #963, these are complementary choices: Scratch provides an isolated non-Git task folder; New project creates a named repository. Neither commit promotes existing Scratch files. If promotion is desired, specify it separately. A failed initial commit also prevents #964’s required-worktree fan-out and must be visible.

    Verification plan

    Cover concurrent names, collisions, Unicode, Windows names, custom branches, missing Git identity, signing failure/timeouts, filesystem failure, and interrupted/lost RPC responses. Verify projected visibility before draft navigation, disconnected/mixed-version environments, machine selection, mobile deep links/back navigation, and existing clone retry/cancel behavior. Publishing failure must retain the local project and use the returned actual path after suffixing. Validate providers with both committed and unborn repositories.

    Actual verification

    Ran git show 148e6deea0, scoped diff reads, and rg comparisons of web/mobile add-project, contracts, normalization, clone tracking, and migration lineage. Initial and final git status --short were clean. No edits, commits, tests, builds, publishing, or runtime verification occurred. Lifecycle and UI behavior remain unverified.

    Read-only design review (Codex via relay, coordinated by Claude Opus 5.5) against Pylon 00884406f7. Decisions stay with the maintainer.

  2. rynfar commented on Oct 2, 2026

    @rynfar
    CollaboratorAuthor

    Decision briefs: product changes in this cycle

    Review baseline: Pylon 00884406f7d8c59c3ee98a617ba8a1eb64661a04, cycle #981. Research only; no files changed.

    b33eda1399

    Recommendation: offer a Pylon-adapted, default-off beta, subject to the maintainer choosing the sidebar behavior.

    Upstream behavior. #13926 adds a collapsed Working section for working and monitoring threads. Approvals, input requests, actionable plans, and failures remain in the inbox; pinned threads retain their placement. The open thread stays visible even when Working is collapsed, and search includes hidden threads.

    apps/web/src/components/Sidebar.logic.ts, Sidebar.tsx, and Sidebar.drag.ts implement classification, return-time ordering, rendering, and drag behavior. Working rows cannot be dragged or receive drops. Enabling the feature replaces manual active ordering with newest-return-first ordering; disabling it restores saved ordering. Mid-turn returns receive client-observed timestamps held in module memory, so those timestamps do not survive reload or synchronize across devices.

    packages/contracts/src/settings.ts adds default-false sidebarWorkingShelfEnabled and its optional patch field. Settings search/reset and the desktop settings fixture change too. There are no orchestration events, projections, or database migrations.

    Current Pylon behavior. Pylon’s Sidebar.logic.ts already reduces prominence for busy rows while preserving visible, static Working, Delegating, and Monitoring indicators. It distinguishes approvals, input, plans, failures, and unread completion, consistent with docs/user/status-indicators.md.

    A direct port misses Pylon’s delegating status: background fleets resolve to Delegating, whereas upstream’s predicate accepts only Working and Monitoring. Pylon’s ThreadSettlementPolicy.ts excludes background liveness and pending actions from automatic settlement. Folding is a presentation decision and must not change those lifecycle rules. ThreadNotificationCoordinator.tsx independently handles attention notifications; moving a row must not generate or suppress notification events.

    Options.

    • Don’t adopt: retain visible, receding busy rows and manual ordering. No contract, migration, client, remote, or Prime changes; negligible effort and risk.
    • Adapt upstream: include Delegating while retaining Pylon’s status precedence, colors, progress counts, and notification semantics. Add the default-off setting and desktop fixture; initially support web/Electron, explicitly leaving mobile unchanged. Environment-scoped keys support local, remote, and tunnel threads, but return ordering remains client-local. No provider behavior, decider/projection change, or SQL migration. Medium size; moderate interaction risk.

    Maintainer decisions. Should delegated fleets and indefinite monitoring both collapse? Is giving up manual inbox ordering acceptable while enabled? Is device-local return ordering sufficient?

    Adoption plan. First define Pylon’s classification and reversal rules; then port grouping, settings, search, navigation, and drag behavior together. Update sidebar/status documentation.

    Verification plan. Run focused Sidebar.logic.test.ts and Sidebar.drag.test.ts tests, plus scoped web/contracts/desktop settings checks. Cover working→approval/input/plan/failure/completion, delegated-work termination, pinned and snoozed precedence, selected-row visibility, enable→disable order restoration, reconnect snapshots, and duplicate thread IDs across environments. Verify isolated web/Electron interaction after browser authorization.

    0a04cc50de

    Recommendation: let the maintainer choose how to extend Pylon’s existing update UI; this is partial overlap, not an already-complete equivalent.

    Upstream behavior. #14678 adds apps/web/src/components/ProviderUpdatesAction.tsx to the Providers settings header. “Update all” gathers eligible outdated providers from every connected environment, displays targets in a tooltip, and concurrently dispatches environment-addressed serverEnvironment.updateProvider commands. Manual-only updates are excluded. A synchronous guard prevents repeat clicks.

    ProviderUpdateLaunchNotification.logic.ts adds ProviderUpdateRun and an aggregate result formatter. It lists each non-success with machine/provider labels, excludes interrupted commands, and returns no toast when all commands were interrupted. The commit adds formatter tests and updating documentation. It introduces no wire schema, persistence migration, orchestration event, or projection change.

    Current Pylon implementation. Pylon already has:

    • ProviderUpdateLaunchNotification.environments.ts: groups the primary backend and desktop-local secondaries such as WSL, excluding SSH/relay/other remote targets.
    • ProviderUpdateEnvironmentRows.tsx: updates all eligible providers within a selected environment, with persistent row feedback, timeout recovery, request-version fencing, and rejection handling.
    • settings/ProviderSettingsPanel.tsx: individual instance updates for the selected environment, with access restrictions.
    • sidebar/SidebarProviderUpdatePill.tsx: ongoing maintenance feedback.

    Thus Pylon has multi-environment discovery and per-environment bulk updates, but no equivalent single action spanning every connected environment.

    Pylon’s backend providerMaintenanceRunner.ts uses providerMaintenanceCommandCoordinator.ts to reject duplicate targets and serialize shared installer operations. Prime’s managed maintenance has separate capabilities and runtime/settings fences; a frontend bulk action must keep using that backend ownership.

    Options.

    • Don’t adopt: retain deliberate environment selection and existing feedback. No contract/migration or client changes; negligible effort. Remote updates remain available through selected-environment settings.
    • Add upstream’s Settings action: small-to-medium web/Electron change; mobile remains unchanged. Reuse existing commands and backend authorization, with no SQL or event-sourcing changes. Covers connected local, WSL, remote, and tunnel environments. Risk: a globally scoped action inside a selected-environment panel can surprise users; interruptions can disappear from the summary.
    • Extend Pylon’s grouped UI: medium size. Add explicit “Update all connected environments” to a reviewed target list, retaining per-environment outcomes and retries. Same contract/provider boundaries; greater implementation work but stronger result visibility.

    Maintainer decision. Choose upstream’s compact global action, Pylon’s grouped interaction, or coexistence with distinct launch-local and Settings-global scopes. Neither implementation should silently replace the other.

    Adoption plan. Establish scope and labeling first; share candidate selection and outcome handling; preserve instance identity, permission checks, installer queues, Prime capability exclusions, and disconnected-environment handling.

    Verification plan. Run focused notification logic/environment-row tests and scoped web checks. Add coverage for multiple environments, partial failure, interruption, missing terminal snapshots, disconnects, duplicate clicks, manual-only providers, differing instance commands, read-only connections, and Prime availability. Reuse backend maintenance regressions; any backend modification needs focused coverage with worker drains rather than sleeps.

    mobile-sdk58

    Recommendation: defer the runtime upgrade until a supported stable Expo/RN combination and Pylon native validation are available. Decide the Android widget replacement separately.

    Current versions. apps/mobile/package.json declares Expo ~57.0.18, React Native 0.86.3, and React 19.2.3.

    What each commit needs.

    • 8dc07f199c / #12045: upgrades to Expo 58.0.0, RN 0.88.0-rc.3, React 19.3.0, and corresponding Expo/navigation/gesture/Reanimated/Worklets dependencies. It changes native header imports and codegen imports, component instance types, gesture APIs, asynchronous filesystem operations, notification presentation, and widget APIs. It removes the custom iOS scene plugin, rebases/adds native patches, changes workspace overrides/lockfile/licenses, and updates web React types. The lockfile raises RN tooling’s Node requirement to supported Node 22/24/26 ranges.
    • 1e9c36023c / #12051: needs SDK 58’s Expo Modules 2.0 macros. Converts function members in composer/native-controls Swift modules to @ExpoModule/@JS, retaining view definitions and main-actor UIKit access. This is a follow-on refactor, not evidence that every Pylon module must convert.
    • e41755cf8a / #12046: needs SDK 58 Android expo-widgets, platform-specific widget config, embedded initial layout, and a new native expiry receiver with boot restoration. It replaces the Kotlin subscription widget.
    • ce920f2ac8 / #12049: needs SDK 58 dev-client launch preferences. Capture tooling passes onboarding/FAB/auto-launch flags through launch URLs; Android gesture/key toggles remain preference-based.

    RC status. The reviewed series still pins and resolves 0.88.0-rc.3; none of the three follow-ups changes that pin. Expo’s 58.0.0 version does not establish RN stability. This finding concerns the frozen series, not today’s registry status.

    Pylon native impact. Audit t3-markdown-text, composer/editor, native controls/keyboard commands, t3-review-diff, t3-terminal, t3-agent-notifications, and pylon-subscription-widget. Pylon-only diff/terminal/notification modules have no upgrade coverage in these commits. Check Swift definitions, Kotlin/Gradle integration, Fabric/codegen, Nitro’s changed CallInvoker installation, and retained patches. Preserve Pylon clipboard, notification, identity, and scene/deep-link behavior.

    Pylon’s Android widget cold-launches the correct variant and supports fitted older-Android rows plus scrolling newer-Android rows. Upstream offers Compose rendering and reboot-restored expiry, but tap navigation requires a live JS runtime and displays only two quotas per provider. Replacement needs a maintainer choice and existing-widget migration consideration.

    Options. Don’t adopt now: no compatibility changes or immediate effort. Adopt the runtime with Pylon adaptations while retaining its widget: large scope/high native risk. Adopt the entire series: larger scope, including the widget product tradeoff. No server decider/projection or SQL migration is needed; mobile is primary, web types also change, and local/remote/tunnel/Prime connections require regression checks.

    EAS/OTA. New native binaries are required; OTA cannot replace native code. Fingerprint runtime versions must change with this native upgrade. Expo runtime-version guidance. Preserve Pylon EAS ownership/channels, default fingerprint policy, and CI host/package-manager consistency. Audit appVersion override profiles and preview’s EAS CLI/action pin.

    Trigger and plan. Reopen when stable RN is supported by Expo and critical native dependencies, or a concrete Pylon blocker justifies RC adoption. First validate dependency/patch resolution and both native builds; then verify composer, markdown, diff, terminal, notifications, widgets, sharing, gestures, backgrounding, and remote reconnects. Finally compare fingerprints and validate new preview binaries before separately authorized release.

    Actual verification: git rev-parse HEAD matched the assigned base; final git status --short was empty and git diff --exit-code 00884406f7d8c59c3ee98a617ba8a1eb64661a04 exited 0. Source inspection used git show, rg, cat, and sed. gh issue view 981 --repo pylon-code/pylon failed to connect. No tests, lint, typechecks, native builds, EAS operations, or device checks ran; the listed verification plans remain outstanding.

    Read-only decision briefs (Codex via relay, coordinated by Claude Opus 5.5) against Pylon 00884406f7. Decisions stay with the maintainer.

  3. rynfar commented on Oct 2, 2026

    @rynfar
    CollaboratorAuthor

    Checkpoint, 2026-10-02 (overnight)

    Merged. Each passed an independent adversarial review at its final head, with green final-head CI.

    Open:

    Decision briefs posted here: 148e6deea0 new project from a name, b33eda1399 Working section, 0a04cc50de update all providers, and the SDK 58 series. The SDK 58 series is recommended for deferral: it pins RN 0.88.0-rc.3; reopen when stable RN is supported.

    Design reviews posted: #963 (also covers 39405f1992), #964, #965, #966.

    Skip/covered, unchanged from triage: 41a8239849, b91e4668fa, a97a4a9d18, a3fb5392e3, 094fb230e9, 2731929610, a3abb52660.

    The cursor stays at 921cb3c8bc until #983 and #986 land and the group G and F decisions are recorded.

  4. rynfar commented on Oct 3, 2026

    @rynfar
    CollaboratorAuthor

    Checkpoint, 2026-10-03 (takeover after the thread stalled)

    The previous agent thread stalled. At 07:21Z, Codex returned Selected model is at capacity and the pre-v2 orchestrator locked the session. Work was resumed from this issue and the PRs.

    Merged since the last checkpoint: #983 (desktop preview, 5cc99e1c23 and 3e60fecf39), plus the v2 prerequisites #987 and #989.

    #986 (mobile: 9962e6986d, 09388bf2da, 438af295fe, bed69f6ea4; 99e08526e5 skipped)

    • Rebased onto 5f1af3418e (head e8ab215139).
    • Added fixes for ktlint and for a stale test import left by the rebase.
    • The Android compile hold is cleared: :t3-agent-notifications:compileDebugKotlin, testDebugUnitTest (108/0/0) and :app:compileDebugKotlin all passed in run 37130302631.
    • All final-head CI checks are green.
    • Range-diff against the reviewed head adee207196: six of the seven commits are patch-identical. The seventh differs only in conflict-resolution imports.
    • Waiting on developer merge approval.

    Remaining for this cycle:

    • Maintainer decisions (briefs are above): 148e6deea0 new project from name, b33eda1399 Working section, 0a04cc50de update-all providers, 39405f1992 mobile "No project" row (with Design review: start threads without a project (upstream #13612) #963).
    • Confirm deferral of the SDK 58 series 8dc07f199c, 1e9c36023c, e41755cf8a and ce920f2ac8. RN is still 0.88.0-rc.3.
    • Skip/covered set is unchanged.

    The cursor stays at 921cb3c8bc until every source has a disposition.

    Release blocker, outside this cycle: every scheduled nightly since 2026-10-01T13:04Z has failed. macOS notarization returns HTTP 403: A required agreement is missing or has expired. Until the Apple Developer account holder accepts the pending agreement, nothing from #983, #986 or #989 reaches installed builds.

  5. rynfar commented on Oct 3, 2026

    @rynfar
    CollaboratorAuthor

    Maintainer decisions, 2026-10-03

    #986 merged as a0a6440b35 and #990 merged as b4c210ea5d. #990 fixes v2 Codex sessions that stayed unusable after the app-server process exited.

    The maintainer chose "adopt all properly for Pylon" for the four product sources. Each is being ported on its own branch from b4c210ea5d, using the recommended adaptations in the briefs above:

    Source Decision Adaptation choices
    148e6deea0 New project from a name Adopt, adapted Separate from "Add existing project". The root is derived from Pylon's runtime identity. Starter files are Pylon-neutral. Includes optional private GitHub publishing. Adds client idempotency identity and cleanup only after a proven rejection.
    b33eda1399 Working sidebar section Adopt as a default-off beta Includes Delegating and Monitoring. Manual order is suspended while enabled and restored when disabled. Return order is device-local. Presentation only; no lifecycle or notification changes. Web/Electron only.
    0a04cc50de Update all providers Adopt by extending Pylon's grouped UI Explicit "all connected environments" action with a reviewed target list and per-environment outcomes and retries. The existing per-environment and per-instance updates are kept.
    39405f1992 Mobile "No project" row Adopt together with Scratch Depends on upstream 6b286ae8a2 (#13612, Scratch projects), whose disposition is owned by #963. Scratch is adopted as an ordinary persisted project with idempotent server-owned allocation and a guard when the base dir is inside a Git checkout. The current machine is preserved, with a consistent fallback to a sole offering machine. Thread deletion keeps the files.

    The SDK 58 series (8dc07f199c, 1e9c36023c, e41755cf8a, ce920f2ac8) stays deferred. Reopen when Expo supports a stable React Native release, or when a concrete Pylon blocker justifies adopting the RC. The skip/covered set is unchanged.

    The cursor advances when these four PRs land. After that, the next cycle covers upstream commits after 99e08526e5.

  6. added a commit that references this issue on Oct 3, 2026
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