Skip to content

sync(provenance): import upstream stack C1..C2 - #345

Merged
patroza merged 1 commit into
fork/devfrom
sync/provenance-2026-08-06
Aug 6, 2026
Merged

sync(provenance): import upstream stack C1..C2#345
patroza merged 1 commit into
fork/devfrom
sync/provenance-2026-08-06

Conversation

@omegent-app

@omegent-app omegent-app Bot commented Aug 6, 2026

Copy link
Copy Markdown

First run of the provenance synchronization from
#342 — and the answer to "get the latest upstream onto
fork/dev". Five upstream commits enter the product:
a2ca89aa feat: native subagent & workflow observability (pingdotgg#5219)
990bb0b6 fix: reconnect faster after remote server updates (pingdotgg#5404)
7251f1a1 Prevent terminal loading flash (pingdotgg#5432)
30e47153 fix(web): preserve terminal font size when splitting (pingdotgg#5444)
de592a00 Enrich terminal font previews (pingdotgg#5428)

54 files, +7,055 / −175.

Checkpoint

{
  "importedCandidatesCommit": "9655a9ba955197361044ef6f8f97e35841ff779e",
  "importedCandidatesTree":   "50f9bfab717c30a8ea90d52060349e209502d116",
  "importedUpstreamCommit":   "a2ca89aa10f13a2222e08afd98c66285121d5ba2",
  "previousCandidatesTree":   "9b4cd3e1c774c3c436e43305c151edf596b2936a"
}

previousCandidatesTree is C1 from tag fork-dev/2026-08-06.1. Tag the merge commit
fork-dev/2026-08-06.2 with the values above once this lands.

Two resolutions worth reviewing

Most of the 7 conflicted files are independent additions on both sides and resolve as unions —
upstream's backgroundLiveness beside identity's originSource/participantSummaries, upstream's
agent-spawn CTA rows beside the imported user-input Q&A timeline. Two were not unions:

apps/web/src/components/Sidebar.logic.ts — the 3-way merge welded upstream's
hasPlanReadyPrompt condition onto the "Wake Required" return body. Left alone, a plan-ready
thread would render as Wake Required and no thread could ever reach Plan Ready. Both
branches are restored with their own bodies. The status rank map is merged onto upstream's new scale
with Wake Required at the Working/Connecting tier — its relative position before the import.
That tier placement is a judgement call; say if you want it ranked differently.

apps/mobile/src/lib/threadActivity.ts — upstream's isAgentInternalActivity skip guard must
run before identity's resolved-user-input enrichment. The other order enriches and pushes exactly
the agent-internal rows upstream means to drop.

Validation

  • All 12 fork/candidates commits replayed onto the rebuilt fork/tim; a2ca89aa1 confirmed an
    ancestor of the new candidates tip.
  • No residual conflict markers; brace balance checked on the hand-edited files.
  • Typecheck and tests have not run locally — the rebase workspace has no node_modules. Fork CI
    on this PR is the first real verification. Do not merge on the strength of this description.

Provenance branches not yet pushed

fork/base → 4a73589 and fork/tim → b1c5fa5 are rebased and fork/candidates → 9655a9ba
is rebuilt, but all three are local only. The ruleset Protect fork/tim, candidates, integration
sets non_fast_forward with no bypass actor and the app token has no administration scope, so I
cannot force-push them. Until they are pushed, importedCandidatesCommit refers to a commit that
exists nowhere on the remote. The tree is what the delta depends on, but the checkpoint is not fully
honest until that push happens.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

@omegent-app
omegent-app Bot force-pushed the sync/provenance-2026-08-06 branch 2 times, most recently from c56468f to 28b9cc9 Compare August 6, 2026 05:54
@omegent-app @patroza
sync(provenance): import upstream stack C1..C2
ceef003 
Imports the tree delta from the fork/candidates tree recorded in the
fork-dev/2026-08-06.1 checkpoint to a rebuilt fork/candidates carrying upstream
main a2ca89a. Five upstream commits enter the product:

  a2ca89a feat: native subagent & workflow observability (pingdotgg#5219)
  990bb0b fix: reconnect faster after remote server updates (pingdotgg#5404)
  7251f1a Prevent terminal loading flash (pingdotgg#5432)
  30e4715 fix(web): preserve terminal font size when splitting (pingdotgg#5444)
  de592a0 Enrich terminal font previews (pingdotgg#5428)

  importedCandidatesCommit: 9655a9b
  importedCandidatesTree:   50f9bfa
  importedUpstreamCommit:   a2ca89a
  previousCandidatesTree:   9b4cd3e

Seven files conflicted against the fork/dev product tree. Most are independent
additions on both sides and resolve as unions: upstream's backgroundLiveness
alongside identity's originSource/participantSummaries, upstream's agent-spawn
CTA rows alongside the imported user-input Q&A timeline.

Two needed more than a union.

apps/mobile threadActivity.ts: upstream's isAgentInternalActivity skip guard
must run before identity's resolved-user-input enrichment. Concatenating the
sides in the other order would enrich and push agent-internal rows that
upstream intends to drop.

apps/web Sidebar.logic.ts: the 3-way merge welded upstream's hasPlanReadyPrompt
condition onto the "Wake Required" return body, so a plan-ready thread would
have rendered as Wake Required and no thread could ever reach Plan Ready. Both
branches are restored with their own bodies. The status rank map is merged onto
upstream's new scale with Wake Required kept at the Working/Connecting tier,
matching its relative position before the import.

Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
@omegent-app
omegent-app Bot force-pushed the sync/provenance-2026-08-06 branch from 28b9cc9 to ceef003 Compare August 6, 2026 06:08
@patroza
patroza marked this pull request as ready for review August 6, 2026 06:14
@patroza
patroza merged commit ae4719b into fork/dev Aug 6, 2026
9 checks passed
@omegent-app omegent-app Bot mentioned this pull request Aug 6, 2026
Merged
patroza added a commit that referenced this pull request Aug 6, 2026
@omegent-app @patroza
fix(mobile): declare the release_branch input on EAS development (#346)
cc023c1 
The first `fork/dev` sync merge (`ae4719b1c`, #345) passed **every
required check** and still ended
as a **failed run**:

```
Check ✅  Test ✅  Mobile Native Static Analysis ✅  Release Smoke ✅  Classify Deployment Scope ✅
Dispatch Mobile Releases ❌  HTTP 422: Unexpected inputs provided: ["release_branch"]
```

Because the deploy poller only promotes a SHA whose `fork-ci` run
**concluded success**, that one
failure blocked server, Discord, desktop and VS Code deployment of
`ae4719b1c` entirely. The guest is
still sitting on `21badd04e`.

## Cause

[#344](#344) added the
`release_branch` input **declaration**
to `mobile-eas-production.yml`, but for `mobile-eas-development.yml` it
only rewrote the *usages* —
leaving the file referencing `inputs.release_branch` without declaring
it. Production dispatch
succeeded; development was rejected.

The validation in that PR printed the default for production and nothing
for development. That was
the evidence, and it was read past.

## Change

Declare the input with the same `fork/integration` default, so a manual
dispatch that omits it
behaves exactly as before.

## Validation

Rather than eyeball it again, all three workflows are now checked for
`inputs.*` references with no
matching declaration:

```
fork-ci.yml                | declared: checkout_ref                                    | undeclared: none
mobile-eas-production.yml  | declared: mode,platform,message,runtime_version,sha,release_branch | undeclared: none
mobile-eas-development.yml | declared: platform,runtime_version,sha,release_branch      | undeclared: none
```

## Separate design question, not fixed here

**Should a release-dispatch failure invalidate a validation verdict?**
`Dispatch Mobile Releases`
performs a *release action*; the other five jobs *validate the SHA*.
Mixing them in one run means any
dispatch hiccup — a 422, a transient API error — marks the SHA
unapprovable and stalls the whole
fleet, which contradicts the handover doc's own rule that per-target
release status is recorded
independently and that one target's failure must not hold back the
others.

Two options, both one-liners:

- `continue-on-error: true` on `dispatch_mobile_releases` — run
concludes success, the failed job
  stays visible, mobile status is tracked by the EAS workflows anyway.
- Move the dispatch into its own `push`-triggered workflow so
`fork-ci`'s conclusion means "this SHA
  is valid" and nothing else.

I did not apply either, because weakening the deploy-approval signal is
a policy call. Say which you
want and I'll do it.

Co-authored by [@patroza](https://github.com/patroza)

opened by [Patrick Roza](https://discord.com/users/95218063095377920) in
chat thread **Discord** ·
[Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399)
· [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17)

Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
omegent-app Bot added a commit that referenced this pull request Aug 6, 2026
@omegent-app @patroza
chore(provenance): record upstream a2ca89a as an ancestor
3a7e7a4 
The C1..C2 tree delta in #345 imported the content of upstream commits
2a04db1..a2ca89a but not their commit objects, so GitHub measured fork/dev
as 5 commits behind pingdotgg/t3code:main while being fully current.

-s ours keeps the tree byte-for-byte and records only the parent link, which is
honest because #345 already landed the content and its checks passed. Recorded
in tag fork-dev/2026-08-06.2 as importedUpstreamCommit.

Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
This was referenced Aug 6, 2026
Merged
Merged
patroza added a commit that referenced this pull request Aug 6, 2026
@omegent-app @patroza
fix(web): show Monitoring on board cards instead of Working (#356)
912340b 
Answering "is Monitoring properly adopted" — **almost**. Three of four
surfaces were fine; board
cards were not, and that was my sync resolution.

## Audit

| Surface | Before this PR |
| --- | --- |
| v1 sidebar pill (`resolveThreadStatusPill`) | ✅ `label: "Monitoring"`,
`pulse: false` |
| v2 sidebar row (`SidebarV2.tsx`) | ✅ `label: "Monitoring"`, no icon,
no shimmer |
| Board column bucketing (`Board.logic.ts`) | ✅ `Monitoring` → working
bucket |
| **Board card (`resolveSidebarV2TopStatus`)** | ❌ rendered as
**Working**, *with* the shimmer |

`resolveSidebarV2Status` correctly returns `"monitoring"`, and
`SidebarV2Status` carries it — but
`resolveSidebarV2TopStatus`, which `BoardCard` reads, folded it into
`Working`.

## Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for
monitoring *on purpose*:

- v1 pill: `pulse: false` for monitoring vs `pulse: true` for working.
- v2 row: *"Steady label, no duty-cycled shimmer: monitoring is calm
background presence, not active
  progress (monitoring-pill D6)."*

A board card gave a watch loop `animate-sidebar-working-text` — the
active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

## Cause

Mine, from the #345 import. The union was `"Working" | "Approval" |
"Input" | "Failed" | "Done"` with
no Monitoring member, and I folded the case in rather than widening it,
with the comment *"reads as
Working rather than inventing one"*. Widening was the right call — the
label already existed in two
other surfaces, so it was not an invention.

## Change

Widen the union and give monitoring the v2 row's calm styling. Board
bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is
live rather than awaiting
review.

## Validation

- `Sidebar.logic.test.ts`: **121 tests pass**, including two new ones
asserting monitoring is calm
  and working still animates, so the two cannot silently collapse again.
- Full recursive typecheck clean — the widened union has no other
unhandled consumers.

Co-authored by [@patroza](https://github.com/patroza)

opened by [Patrick Roza](https://discord.com/users/95218063095377920) in
chat thread **Discord** ·
[Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399)
· [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17)

Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
omegent-app Bot added a commit that referenced this pull request Aug 6, 2026
@patroza @github-actions @omegent-app
docs: record the stable fork/dev development and release branch (#342)
65c3850 
Records the `fork/dev` development and release model — **adopted and
live since 2026-08-06**. This
started as a proposal; the migration then ran ahead of it, so the
document is now the record rather
than the plan.

Documentation only. Every mechanism it describes is already merged and
running.

## The model

`fork/dev` is the default branch, the contributor target and the release
source. It is never rebased.
The provenance stack `main → fork/base → fork/tim → fork/candidates`
stays rebased and feeds
`fork/dev` through reviewed tree deltas, so contributor bases are never
invalidated by an upstream
update.

| In place | |
| --- | --- |
| `fork/dev` cut from green `fork/integration` `21badd04e`, trees proven
identical | tag `fork-dev/2026-08-06.1` |
| Default branch, ruleset, squash-only, required checks | live |
| CI for `fork/dev` PRs and merges | #343 |
| Deployment promoting exact green `fork/dev` SHAs | ops `deploy.env` |
| Validation and release split | #347, #349 |
| First provenance sync, upstream `2a04db134..a2ca89a` | #345, tag
`fork-dev/2026-08-06.2` |
| Upstream ancestry recorded so "behind" reads true | `3a7e7a458` |
| Overlays drained and deregistered | #348 |

## What this revision corrects

The document had drifted from what was actually built:

- **Release is two workflows, not one.** `fork-ci` decides whether a SHA
is valid; `fork-release`
acts on that verdict via `workflow_run`. A release action must never be
able to veto a validation
verdict — when mobile dispatch lived inside `fork-ci`, one failed EAS
call marked a valid SHA
  unapprovable and stranded the whole fleet.
- **Check selection is *not* path-inferred**, and the document
previously implied it should be. Every
PR runs all four required checks; only *release* scope is classified. A
path filter that errs
narrow silently skips a check on a protected branch, which is worse than
a slightly slower suite.
- **`fork/changes` and `fork/integration` are frozen**, not fallbacks.
- Ops parameterization and the `deploy.env` cutover are **done**, not
pending.
- Steps that were "do now" are recorded as done, with real SHAs, tags
and ruleset contents.

## What the cutover surfaced

Added as a section, because each cost a round trip and the old path hid
all of them:

- `fork/dev` had **no CI path at all** — no `push` trigger, not listed
as a `pull_request` base.
- **Mobile releases would have stopped silently**; nothing errors when a
gated job just never fires.
- Both mobile workflows **hardcoded `ref: fork/integration`** and
rejected every `fork/dev` SHA.
- A release failure could **strand the fleet**.
- **Every PR based on `fork/changes` was already broken** by earlier
rebases — GitHub reported them
as 60–100 commits and 629–741 files. Each was one commit of real work on
stale history, fixed by
  cherry-picking that commit rather than replaying the branch.

That last one is the clearest evidence for the whole premise: the old
model was silently corrupting
in-flight work, and nobody could see it.

## Deliberately not done

Clean downstream projection is deferred indefinitely and nothing depends
on it. Provenance sync stays
manual. The overlay machinery is still present and still passes its
tests with an empty manifest;
removing it touches ~20 files and is a separate decision.

## Still open

PRs #317, #226 and #185 conflict when cherry-picked onto `fork/dev`;
#237 and #238 live in an
external fork and need their author. `fork/changes` and
`fork/integration` can be deleted once those
are drained.

## Also: no guidance targets an overlay any more

The overlays were drained in #348, but the instructions an agent or
contributor actually reads before
opening a PR still sent them at `fork/discord`, `fork/vscode`,
`fork/identity`, the desktop
deep-links branch, or `fork/changes`. Left alone, the next client-owned
change would have been opened
against a **closed overlay on a frozen branch**.

- **`CLAUDE.md`** (`AGENTS.md` symlinks to it): branch from and target
`fork/dev` for every kind of
work; `main`, `fork/changes` and `fork/integration` named as bases never
to use; the
"register an `integrationOverlays` entry" instructions replaced with a
record that it is empty.
- **`apps/discord-bot/docs/agent-turn-rules.md`**: recovery branches
pointed at *"the correct base
  (`fork/discord` overlay / `fork/changes` / etc.)"* → `fork/dev`.
- **`fork-stack.md`, `stack-ship-path.md`, `client-overlays.md`**:
bannered as superseded rather than
rewritten — the provenance stack they document is still current and they
are the record of how the
fork worked before the cutover. The two lines that literally instructed
a base are corrected.

Verified by grep: nothing in the repository still directs a PR anywhere
but `fork/dev`.

## Validation


`vp fmt --check` clean; internal anchors checked. Documentation only —
no code, tooling or workflow
changes in this PR.

Co-authored by [@patroza](https://github.com/patroza)

opened by [Patrick Roza](https://discord.com/users/95218063095377920) in
chat thread **Discord** ·
[Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399)
· [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17)

---------

Co-authored-by: T3 Code PR Stack <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@patroza