feat(runtime): report task and workflow process identity

[kwakayama]

Task and workflow responses now report the actual service process that entered execution. Runtime identity is captured before tenant code and returned only after task admission or workflow executor activation, including resumed workflows. Expired deadlines, missing targets, input validation failures and other preflight refusals carry no process identity. Failures after execution starts retain attribution, and result JSON remains unchanged.

Consumer for veryfront/veryfront-api#6664 and API producer PR veryfront/veryfront-api#6691. Deploy this framework consumer first. Older consumers remain compatible with the API producer and omit attribution.

Validation: handler and task runner suites pass 490 steps; workflow executor, workflow control and runtime identity suites pass 121 steps. Changed-file typecheck, lint and diff checks pass. Full repository pre-push checks also pass: formatting, lint, public entrypoint typecheck, all 24 parallel unit-test batches, serial tests and working-directory suites. Regression tests fail without the execution-entry fix and pass with it. Coverage includes all four builtin task refusal paths, real task schema rejection and body failure, workflow schema rejection, missing/terminal resumes, and admitted initial/manual-resume attribution.

Previous installed-package proof completed task and workflow on each of two local processes with distinct runtime IDs and four execution IDs, preserving structured output. The final reviewed package, aligned consumer pins and staging qualification remain pending; the release lane will rerun that proof after this PR merges.

[github-actions]

📦 Client bundle boundary

Entrypoint	Modules	Source size	Server leaks
src/index.client.ts	65	359 KiB	✅ 0
src/react/components/Head.tsx	5	74 KiB	✅ 0
src/react/router/index.tsx	5	74 KiB	✅ 0
src/react/context/index.tsx	5	74 KiB	✅ 0
src/react/fonts/index.ts	6	81 KiB	✅ 0
src/react/components/ui/index.ts	111	714 KiB	✅ 0
src/react/components/ui/adapter/contract.ts	1	18 KiB	✅ 0
src/react/components/ui/icons/index.ts	3	17 KiB	✅ 0
src/chat/index.ts	300	2010 KiB	✅ 0
src/chat/ag-ui.ts	59	451 KiB	✅ 0
src/chat/protocol.ts	1	11 KiB	✅ 0
src/chat/types.ts	45	240 KiB	✅ 0
src/chat/message-prep.ts	65	506 KiB	✅ 0
src/markdown/index.ts	6	30 KiB	✅ 0
src/mdx/index.ts	2	2 KiB	✅ 0
src/agent/identity-contracts.ts	1	2 KiB	✅ 0
src/schemas/index.ts	42	214 KiB	✅ 0
src/platform/env.ts	5	53 KiB	✅ 0
src/workflow/claude-code/react/index.ts	9	88 KiB	✅ 0
src/events/index.ts	30	561 KiB	✅ 0
src/events/ag-ui/public.ts	29	555 KiB	✅ 0
src/run-events/index.ts	53	314 KiB	✅ 0

A server module in a client graph aborts hydration in the browser. New leaks fail CI; known leaks are tracked in scripts/lint/client-bundle-baseline.json to burn down.

[kwakayama]

Codex independent review

Reviewed SHA: 20adf95f22b6290e57cdac084be07e938ba909fe

Findings

No actionable findings.

The implementation matches the bounded framework-consumer contract from veryfront/veryfront-api#6664. ProjectRunExecuteHandler completes body parsing, signature verification, and project binding before adding identity headers, so request-validation and authentication failures return without process attribution. It snapshots the existing service runtime ID, encoded display name, and service mode before executeProjectRun, and it continues to serialize the original limited.wireJson, leaving task/workflow output unchanged. The API producer's parser uses these same three headers and accepts them only from HTTP 200 JSON execution responses.

Verification

• Reviewed 084dec99dabae202260e82ceea1ba128996479c0...20adf95f22b6290e57cdac084be07e938ba909fe (3 files, 44 insertions).
• Pinned Deno 2.7.7: focused handler suite passed, 13 tests / 438 steps.
• Pinned Deno 2.7.7: deno check --frozen passed for both modified TypeScript files.
• Changed-file deno lint, deno fmt --check, git diff --check, public-doc validation, and guide-snippet validation passed.
• No unresolved review threads. GitHub CI still has pending jobs and the PR remains draft; those lifecycle gates are outside this code verdict.

Verdict: APPROVE

Score: 98/100

Review-Gate:
Reviewer: Codex
Reviewed-SHA: 20adf95
Score: 98/100
Actionable-Findings: 0
Verdict: APPROVE

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[kwakayama]

Independent review — 20adf95f2

Scope: 3 files, +44 lines. Extends ProjectRunExecuteHandler to emit x-veryfront-runtime-{id,mode,name} response headers for accepted task and workflow executions, matching the existing agent-stream pattern. Adds two parameterized tests (task, workflow) plus a negative assertion on validation rejections. Updates docs/guides/runs.md with a process attribution section.

Verification

All 13 test suites (438 steps) in project-run-execute.handler.test.ts pass, including the two new attribution tests and the extended rejection assertion:

returns runtime process attribution for an accepted task ... ok (2ms)
returns runtime process attribution for an accepted workflow ... ok (1ms)
returns the execute request validation detail: Invalid canonicalRunId ... ok (2ms)
...
ok | 13 passed (438 steps) | 0 failed (10s)

Limitation: did not run full repository suite; verified only the changed file.

Findings

F1 — Informational: identity headers on execution-phase errors
The builder.withHeaders(...) call at L5764 runs after validation but before withSpan. If execution throws and the catch block at L5847-5860 builds the error response from the same builder, the identity headers are included on error responses too. In agent-stream, headers are added only on 200 with SSE body. This is likely intentional per the spec ("framework returns accepted identity headers captured before tenant execution") — the API knows which process accepted the work even if execution failed. Flagging for awareness, not a blocker.

F2 — Informational: RuntimeEncodeURIComponent primordial alias
L200 captures encodeURIComponent before tenant code can replace it, consistent with the TaskDate/TaskError pattern in this file and RuntimeEncodeURIComponent in routes.ts. Correct defensive practice.

Standards

• Smallest viable diff — yes, 3 files, all directly related.
• Test-before-behavior — new tests cover both kinds and the negative case.
• Reuses existing getServiceRuntimeIdentity, RUNTIME_*_HEADER constants, and builder.withHeaders pattern.
• Doc update follows public copy rules (sentence case heading, no em dashes, concise).
• No new dependencies added.
• No security concerns: headers contain a per-process UUID and hostname, both already exposed on agent-stream responses.

Verdict

Clean, focused diff. Achieves parity with agent-stream identity headers for task and workflow executions. Tests pass and cover the positive and negative paths. No regressions or blockers found.

Score: 95/100 — minor note on error-path header inclusion (F1), otherwise exemplary.

---

Review-Gate: PASS
Reviewer: Claude
Reviewed-SHA: 20adf95
Score: 95/100
Actionable-Findings: 0
Verdict: APPROVE

[github-actions]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-16T10:18:58.132939Z	865dab4	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[kwakayama]

@codex review

Please retry the automated review for exact head 20adf95. The ready-for-review invocation reports failed, with no submitted review or inline findings. Independent Codex and Claude reviews are already posted; this requests the required native gate, without bypassing it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 20adf95f22

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kojiwakayama]

Fixed the three review findings in exact head 4762c95225c34ac35401e68812a4d58452ba6ea1.

Pinned Deno 2.7.7 verification: handler suite 13 groups / 442 steps; docs 66 groups / 281 steps; both changed TypeScript files typecheck; changed-file lint/format and diff checks pass. Four setter-forgery/admission-refusal regressions demonstrably fail on the old handler and pass with the fix. Mandatory uncommitted and refreshed-base Codex reviews report no actionable findings.

The PR remains draft while fresh CI/review and final deployed staging qualification are pending. API producer veryfront/veryfront-api#6691 remains open, so this does not claim deployed persistence/projection qualification.

@codex review

[chatgpt-codex-connector]

💡 Codex Review

veryfront-code/src/server/handlers/request/project-run-execute.handler.ts

Line 5791 in 4762c95

executionOwned = true;

Set execution ownership only after runtime entry

Fresh evidence after the prior admission fix is that this flag is still set before executeProjectRun() reaches its own execution-entry checks. For example, an already-expired task returns RUN_TIMEOUT and calls acknowledgeNotStarted without invoking task code, while missing tasks and workflows return their not-found failures without entering execution; all of these responses nevertheless receive the runtime headers and can be persisted as accepted process snapshots. Propagate actual task/workflow entry state instead of marking the dispatch owned before these refusal paths.

AGENTS.md reference: AGENTS.md:L26-L28

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kwakayama]

Independent Codex review of local candidate 641f7a8d9c043d595bca5ba2a76804c8dee6d5d6 against base e572bde87acd4915da21176ca8844ccea3471fbd.

No actionable findings.

The candidate fixes the prior execution-boundary concern. Discovered tasks mark ownership in runTask immediately before admitted task code. Workflows mark ownership through executor onStart, after durable execution admission and before dynamic node resolution. Expired or aborted tasks, missing targets, invalid task or workflow input, missing or terminal workflow resumes, and stale or held resume boundaries omit runtime headers. Failures after task or workflow entry retain the receiving process identity.

The process identity and encoded display name are captured before tenant execution. Final response decoration uses captured native response/header operations, so tenant changes to Headers.prototype.set cannot forge attribution. The existing serialized response body is copied unchanged, preserving output values and normal initial/resume behavior. Authentication and stop/pause ownership paths remain unchanged.

Verification performed with the repository-pinned Deno 2.7.7:

• Handler plus task runner: 14 tests, 489 steps, 0 failures.
• Workflow executor, workflow run control, and runtime identity: 10 tests, 121 steps, 0 failures.
• Changed-file typecheck: passed with --unstable-sloppy-imports --frozen --config=deno.json.
• Changed-file lint and formatting: passed.
• git diff --check: passed.
• Reviewed the complete BASE...HEAD diff and traced all affected task, eval, builtin, workflow start/resume, admission-refusal, cancellation, and response-hardening paths.

Score: 98/100 (correctness 40/40, tests 20/20, reliability/security 15/15, repository standards 14/15, scope/docs 9/10).

This is an approval of the exact local candidate only. The PR remote head is still 4762c95225c34ac35401e68812a4d58452ba6ea1; this comment is not the final remote review gate until 641f7a8d9c043d595bca5ba2a76804c8dee6d5d6 is pushed.

Review-Gate:
Reviewer: Codex
Reviewed-SHA: 641f7a8
Score: 98/100
Actionable-Findings: 0
Verdict: APPROVE

[kwakayama]

Independent Review — 641f7a8d9

Three commits move process attribution from the dispatch-accepted boundary to the actual-execution-admitted boundary. Headers x-veryfront-runtime-id, x-veryfront-runtime-mode, and x-veryfront-runtime-name are set only after the onExecutionOwned callback fires; refusal before admission omits them.

Findings

F1 (low): No explicit test for workflow failure-after-admission retaining headers.
The task path has reports actual task entry for throws task input or execution (handler.test.ts:1391-1425) asserting the runtime-id header survives a throw after entry. No symmetric workflow test exists. The handler catch path at handler.ts:5889 wraps the error response with withRuntimeIdentity(..., executionOwned), so behavior is correct when onStart has fired -- the gap is in explicit verification, not logic.

F2-F4 (informational): executionEntered vs executionOwned divergence is intentional and sound. Knowledge-ingest admission points correctly treat validation as pre-admission. Captured intrinsics (RuntimeEncodeURIComponent, HeadersSet, copyNativeResponse, frozen HostResponse prototype) protect against tenant replacement -- validated by the header-setter protection test.

Verification

deno task test:file src/task/runner.test.ts
  ok | 1 passed (33 steps) | 0 failed

deno task test:file src/server/handlers/request/project-run-execute.handler.test.ts
  ok | 13 passed (456 steps) | 0 failed

Candidate is local, not yet pushed to the remote.

Review-Gate:
Reviewer: Claude
Reviewed-SHA: 641f7a8d9c043d595bca5ba2a76804c8dee6d5d6
Score: 92/100
Actionable-Findings: 1
Verdict: APPROVE

[kwakayama]

Independent Codex Review — local candidate 865dab4947892bb2cf5209d5ae27fbb5a8055f97

Verdict: APPROVE — 98/100. I found no actionable correctness, security, reliability, or maintainability issues in the full e572bde87acd4915da21176ca8844ccea3471fbd...865dab4947892bb2cf5209d5ae27fbb5a8055f97 diff.

The earlier native review concern is resolved at the root contract. Task attribution now flips only through runTask immediately after schema validation and the final abort check, directly before task code. Workflow attribution now flips through the executor's onStart callback after durable activation and before dynamic step resolution. Missing/expired targets, invalid schemas and built-in inputs, observation admission rejection, and missing/already-terminal resumes therefore omit runtime identity. Failures after actual entry retain it.

The new regression at project-run-execute.handler.test.ts:1410 closes the remaining coverage gap by running the real workflow executor, throwing during dynamic step resolution after admission, and asserting the ID, mode, and encoded name headers. The response wrapper uses captured host response/header intrinsics and reuses the already-limited body stream, so it does not alter structured output; the surrounding auth, cancellation, stop-evidence, and manual pause suites remain green.

Verification performed on the local candidate:

• handler + task runner: 14 tests / 490 steps passed
• workflow executor + run-control: 7 tests / 121 steps passed
• changed TypeScript lint: 4 files passed
• changed-file formatting: 5 files passed
• full diff and all admission callback callers/failure paths inspected

This is review evidence for a local candidate only. GitHub still reports remote PR head 4762c95225c34ac35401e68812a4d58452ba6ea1; push 865dab4947892bb2cf5209d5ae27fbb5a8055f97 and rerun exact-head CI/gate checks before treating this as merge evidence.

Review-Gate:
Reviewer: Codex
Reviewed-SHA: 865dab4
Score: 98/100
Actionable-Findings: 0
Verdict: APPROVE

[kwakayama]

Claude Code Review: PR #5185 @ 865dab4

Candidate SHA: 865dab4947892bb2cf5209d5ae27fbb5a8055f97 (local, not yet pushed)
Base SHA: e572bde87acd4915da21176ca8844ccea3471fbd
Scope: 5 files, +459/-22 lines across handler, runner, tests, and docs

Summary

This candidate implements process attribution for task and workflow executions. The runtime
identity (id/mode/encoded-name) is reported in response headers only when execution is
actually admitted -- not on dispatch acceptance or pre-execution refusal. The onExecutionOwned
callback threads through all execution paths (discovered tasks, builtins, evals, workflows
including resume), and the onExecutionStarted callback in the task runner fires after input
validation and abort checks but before task code runs.

Correctness (40/40)

Admission boundary placement is correct across all paths:

• src/task/runner.ts:420: onExecutionStarted fires after signal?.throwIfAborted() (line 419)
  and after input validation (line 378-394). Invalid input and pre-aborted signals correctly
  skip the callback.
• executeKnowledgeIngestRun: Two modes both place onExecutionOwned after validation --
  index_existing_canonical at line 4343 (after file integrity checks), batch mode at line 4436
  (after source collection and empty-check).
• executeReleaseAssetBuildRun (line 4908), executeDependencyArtifactBuildRun (line 5043),
  executeStyleArtifactBuildRun (line 5349+): All call onExecutionOwned after config parsing
  and abort check, before actual build work.
• executeEvalRun (line 4731-4732): onExecutionOwned fires after eval resolution and config
  preparation, before deps.runEval.
• Workflow initial start: onStart on the executor config (line 2035) fires inside
  workflow-run-control.ts:983 after the run is persisted and heartbeat is set up.
• Workflow resume: Same onStart fires through the resumed executeWorkflowRunControl path.

Header injection is tamper-resistant:

• withRuntimeIdentity (line 5819-5827) uses copyNativeResponse to create a HostResponse
  with frozen prototype, then uses captured HeadersSet via IntrinsicReflectApply, bypassing
  any project-replaced Headers.prototype.set.
• RuntimeEncodeURIComponent is captured at module load (line 202), before project code runs.

Refusal paths correctly omit headers:

• executionOwned starts false (line 5836) and is only set true by the onExecutionOwned
  callback (line 5867-5869). All pre-admission failures (missing task, missing workflow,
  expired deadline, invalid eval, observation rejection) return before onExecutionOwned fires.
• withRuntimeIdentity returns the response unchanged when executionOwned is false (line 5820).

Failure-after-admission retains headers:

• The catch block (line 5888-5900) wraps the error response in withRuntimeIdentity with the
  current executionOwned value, which is true if execution was admitted before the failure.
• Workflow discovery failure after executionEntered = true (line 1964) still flows through
  the same onExecutionOwned callback from the executor's onStart.

Tests (19/20)

Comprehensive new coverage (280+ lines of tests):

• Refusal cases: expired task, missing task, eval without id, missing eval, missing workflow,
  missing workflow resume, invalid builtin targets (4 variants), completed workflow resume,
  missing workflow resume, observation admission rejection (task + workflow).
• Admission cases: accepted task, accepted workflow, task with invalid input vs throwing task,
  workflow failure after actual entry.
• Tamper resistance: replaced Headers.prototype.set test for both task and workflow.
• Pause/resume: existing manual pause test updated to assert expectRuntimeAttribution = true
  for both initial and resumed dispatches.
• src/task/runner.test.ts: Four-mode test (valid/invalid/aborted/throws) verifies callback
  ordering relative to task code.

Minor gap (-1):

• No test for a builtin task (e.g. knowledge-ingest, release-asset-build) that succeeds and
  verifies the runtime headers are present on success. The new builtin tests only cover refusal
  (invalid target). The general accepted-task test uses a discovered task via the default
  createDeps. This is low risk since the plumbing is identical, but a single positive builtin
  assertion would close the gap.

Reliability and Security (15/15)

• Identity is frozen at first access (Object.freeze in runtime-identity.ts:63), stable
  per process. A new process gets a new UUID.
• All intrinsics (HeadersSet, encodeURIComponent, Reflect.apply) are captured at module
  scope before any project code can replace them.
• copyNativeResponse creates an independent HostResponse with a frozen prototype, so project
  code cannot intercept header writes on the returned response.
• The signal.throwIfAborted() before every onExecutionOwned call prevents attribution on
  cancelled-before-work runs.
• Name encoding uses pre-captured encodeURIComponent and the name is validated at
  initialization (max 128 code units, no control characters, valid Unicode).

Repo Standards (15/15)

• Follows existing patterns: callback threading through deps, intrinsic capture at module scope,
  copyNativeResponse for header manipulation.
• Tests use existing signedRequest/createDeps/withMockFetch utilities.
• Documentation update in docs/guides/runs.md follows public copy rules (no em dashes,
  sentence case, direct language, present tense).
• No new dependencies added. Minimal diff surface.
• Imports follow #veryfront/* convention.

Scope and Docs (10/10)

• Scope is tightly focused on the attribution contract. No unrelated changes.
• docs/guides/runs.md addition explains the contract, header names, rollout dependency,
  backward compatibility with older runtimes, and deployment order.

Verification

deno task test:file src/task/runner.test.ts
ok | 1 passed (33 steps) | 0 failed (58ms)

deno task test:file src/server/handlers/request/project-run-execute.handler.test.ts
ok | 13 passed (457 steps) | 0 failed (9s)

All tests pass. Candidate is local (not yet pushed to remote).

Gaps

1. No positive builtin-task attribution test (low risk, optional).

Review-Gate:
Reviewer: Claude
Reviewed-SHA: 865dab4
Score: 94/100
Actionable-Findings: 0
Verdict: APPROVE

[kwakayama]

Addressed the execution ownership finding in 641f7a8d9c043d595bca5ba2a76804c8dee6d5d6, with the requested workflow failure regression added in 865dab4947892bb2cf5209d5ae27fbb5a8055f97.

Ownership now comes from actual execution entry, rather than dispatching executeProjectRun: the task runner signals immediately before admitted task code, the workflow executor's existing onStart signals activation for initial and resumed runs, and eval/builtin executors signal after their own validation. Expired tasks, missing task/workflow/eval targets, invalid input and unadmitted resumes omit all three runtime identity headers. Once execution starts, failures retain the trusted process identity.

Regression evidence: the refusal cases failed before the fix; removing either actual-entry hook fails the corresponding positive controls. Restored implementation passes handler + task runner (490 steps), workflow executor/control/process identity (121 steps), changed-file typecheck/lint and repository formatting/lint/public entrypoint typecheck. The new real dynamic-workflow failure test asserts execution occurred, the response failed, and all three exact runtime headers remain present.

[kwakayama]

@codex review

Please review published head 865dab4947892bb2cf5209d5ae27fbb5a8055f97. The execution-entry finding and follow-up workflow failure coverage are addressed in the fix evidence. Fresh independent reviews for this exact head passed with zero actionable findings: 98/100 and 94/100. Focused verification passes; full repository hook and hosted CI are running. Merge remains gated on all checks.

[github-actions]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 865dab4947

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud