Skip to content

Re-pin vendored Interchange to the workflow.json retirement, rebased - #87

Closed
TheGreatAxios wants to merge 6 commits into
mainfrom
cl-6324-deploy-conversion
Closed

Re-pin vendored Interchange to the workflow.json retirement, rebased#87
TheGreatAxios wants to merge 6 commits into
mainfrom
cl-6324-deploy-conversion

Conversation

@TheGreatAxios

@TheGreatAxios TheGreatAxios commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Supersedes the held #59: same re-pin (59f5e7b94ed8baf4, the
workflow.json retirement), now rebased onto post-merge main with the
vendored deltas that landed today re-applied onto the re-vendored trees.
The app-side deploy conversion is not here — see "What remains", which
now carries the ordering proof rather than a scoping guess.

What this lands

  • Rebased onto main (133 commits since Re-pin vendored Interchange to the workflow.json retirement #59's base). Four conflicts,
    all resolved by keeping the re-vendored trees and folding main's own
    vendor deltas back on top: vendor/intx/workflow-host/src/index.ts
    (adapter exports beside the renamed spawners), VENDORED.md,
    scripts/checks/kill-dates.txt, docs/revendor-inventory.md.
  • CL-6325: action-handler registry (invokeAction bind, workbench half) #58's workflow-host adapters + child binding re-applied.
    adapters/{action-invoker,effect-ledger,run-blobs}.ts and the
    resolveActionHandler / effects / invokeAction wiring in
    child/run-child.ts re-diff onto 4ed8baf4 without conflict, still
    typecheck against the re-pinned tree, and their 14 tests pass.
  • CL-6326: onTrigger non-fatal body-failure edge (onBodyFailure) #68's onTrigger.onBodyFailure edge re-applied. Upstream's 486a6b1b
    reshaped runtime/run.ts across the re-pin; the delta re-applies onto the
    new drive loop and planOnTriggerResume unchanged, 4 tests pass.
  • Kill-date tree hashes re-recorded for vendor/intx/workflow and
    vendor/intx/workflow-host; check:killdates is green, and both
    VENDORED-FROM delta lines carry the re-applied sub-deltas.
  • Docs: the CL-6325/CL-6326 rows no longer say "re-apply after the
    re-pin" — they are re-applied — and docs/revendor-inventory.md gains the
    ordering proof below.

What remains, and why it could not be forced

The conversion is one chain, and step 3 is the only one that touches the
sites the typecheck is red on:

  1. packages/folded-runs' deployAtHead must become a code-sourced deploy.
    deployWorkflowFromSource takes a WorkflowDefinitionSource — a
    registry pin, an asset tarball selected by name@range, or an asset
    source tree at a commitSha. Grepping apps/, packages/,
    workflows/, scripts/ for deployWorkflowFromSource returns zero
    hits: workbench has no code-sourced deploy caller at all. This is a new
    pipeline (definition asset, seeded source tarball, registry config,
    attachment resolver, asset service), not a call-site rename.
  2. A folded run's definition is per-run; a seeded tarball is not. It varies
    by systemPrompt, trigger.to, the resolved inference chain, and the
    @corbits/mcp-tools credential bindings folded in at launch. The varying
    half has to move into deploy-time config the entry module reads — a
    change to the folded-run contract, not a port.
  3. Only then can the sidecar convert. SpawnTimeEnv drops
    referencedDefinitionHashes and gains closurePackageDir; the new
    createInMemorySpawnChild / createInMemorySpawnSuspendableChild take a
    bodies: ReadonlyMap<string, WorkflowDefinition> lifted from the
    re-evaluated closure. There is no closure dir to stage and no bodies map
    to lift until step 1 ships one. Swapping the spawners first would mean
    re-deriving bodies from the retired in-memory definition — the fallback
    shim recreating the deleted front, which is ruled out.

So the spawn swap was deliberately not landed half-way.

Section deploys (CL-6329 / Phase 1.3's prerequisite)

Checked against the re-vendored trees: section deploy works on the new
rails, natively, and the launch API needs no single-step/section branch.

  • deployCodeSourcedWorkflow (hub-sessions/src/session-service.ts:745)
    calls enumerateInertOnTriggerBodies(projection) on EVERY code-sourced
    deploy, pins each body step's source through the same operator-approval
    gate as the top-level steps, recomputes each body's wire hash, and ships
    them as referencedDefinitions. No caller opt-in, no second entry point;
    a definition with no inline section enumerates zero bodies.
  • Which shape deploys is therefore purely a property of what the source
    package's entry module evaluates to. A converted deployAtHead exposing a
    "this one is a section" flag would model a distinction the platform does
    not have.

Two seam corrections against the new pin:
workflow-deploy/src/orchestrator.ts:1020 no longer exists (the file went
1094 → 319 lines; createWorkflowDeployOrchestrator is deleted, and body
enumeration moved into hub-sessions plus the pure
inert-ontrigger-bodies.ts). workflow/src/ontrigger-bodies.ts:43
(onTriggerBodyRef) is intact and is now the single owner of the
<workflowId>__<stepId> scheme.

One finding Phase 1.3 should know: onBodyFailure is dropped by the inert
projector — projectOnTrigger (live-inert-projector.ts:376) is an explicit
whitelist and InertOnTrigger has no such field. It still works on the new
rails, because the child re-evaluates the closure to a LIVE definition and the
runtime reads the policy off that (run-child.ts:645-649); being outside the
projection also means it can never cause a re-verify divergence. But it is
sound only on a path whose executable definition is re-evaluated from
source. Any path that ships the projection as executable would silently take
the default "end" — a section dying on its first failed turn, with no
error.

State of the build

  • folded-runs: 38 pass / 0 fail. chat: 548 pass / 0 fail.
  • apps/sidecar: 121 pass, 3 fail — all three the deleted
    createWorkflowSpawnChild export, the visible tail of the chain above.
  • bun run typecheck: red at exactly the four mapped sites
    (folded-runs' two deploySingleStepAtHead references and their cascade,
    and the sidecar's projection.definition / spawn-adapter /
    referencedDefinitionHashes / workflowDefinitionRepoId sites). One
    further error, vendor/intx/inference/src/providers/google-genai-files.ts
    Uint8ArrayBodyInit, is byte-identical to main and predates this
    branch.
  • Lint and format clean; check:killdates green.

Draft until the folded-run source-package decision (step 1/2) is made.

Upstream's 45 commits since 59f5e7b9 retire the on-disk workflow.json: a
deployed workflow's definition is evaluated from its own source closure and
re-verified in-child against the approved wire hash, source-ref becomes the
only deploy lineage, childWorkflow becomes an owned inline import resolved
in memory, and run grants derive from a persisted grant-walk snapshot.

Re-applies every workbench-local delta on the new trees, none of which
upstream subsumed: the inference.usage forward, the terminal-anchor
ownsWorkflowRunRepo gate, the hasConversationText mail drop, and the
hub-api needs-you approval route carve-out. Their tests stay green.

apps/sidecar keeps its old row: the execution host has not been converted
off the retired lineage yet.
Upstream deleted the live-config wrap (wrapHarnessAsSingleStepWorkflow)
along with the rest of the live-authored deploy chain. The wrap was a thin
adapter over buildSingleStepAgentDefinition, which survives, so the launch
now passes the resolved fields directly: the folded run's id, its system
prompt, and its catalog-resolved inference preferences. Tools stay empty
here — a folded launch pins its tools as packages, not factories.
Records the CL-6324 pin delta, the deltas that survived it, and why the
app-side conversion is one migration rather than a per-tree bump: workbench
has no code-sourced deploy front, and the retired live-authored chain is
what every folded run launches through.
The CL-6325 action-handler adapters and the CL-6326 onBodyFailure edge
re-apply onto the 4ed8baf4 trees unchanged; their tests stay green, so
only the recorded tree hashes move.
Records that the #58 workflow-host adapters and the #68 onTrigger
onBodyFailure edge re-apply onto the 4ed8baf4 trees unchanged, and why
the four open conversion sites can only be taken in one order: no source
closure exists to stage or lift bodies from until the folded run itself
deploys from a real source package.
…Failure is read

Records that the code-sourced deploy enumerates inline onTrigger bodies
unconditionally, so one launch front serves both a single-step agent and a
section definition, and that onBodyFailure reaches the runtime only because
the child re-evaluates the closure -- the inert projector drops it.
@TheGreatAxios

Copy link
Copy Markdown
Contributor Author

Superseded — the repo is pinned to @intx/inference 0.3.0 and the vendored trees were retired to published-only consumption.

@TheGreatAxios
TheGreatAxios deleted the cl-6324-deploy-conversion branch August 25, 2026 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant