@inflexa-ai/harness 0.13.0 → 0.14.1

package/dist/state/index.js

@@ -10,11 +10,11 @@ export { initCortexState } from "./init.js";
 export { upsertAnalysis, resolveAnalysisBilling, suspendAnalysis, resumeAnalysis, loadAnalysisStatus } from "./analyses.js";
 export { upsertArtifact, upsertArtifacts, queryInputArtifacts, queryStepArtifactPaths, queryUnsyncedStepArtifacts, updateArtifactId, updateFileIds, countArtifactsForRun, } from "./artifacts.js";
 export { insertRun, reserveRunById, RunDedupCollisionError, RunIdentityCollisionError, updateRunStatus, promoteFailedToPartial, setRunMandate, // oss-core-managed-ok: run-mandate ledger (nullable; OSS leaves null)
-setRunSynthesisOutcome, queryRun, queryActiveRun, queryRunsByAnalysis, queryRunsByThread, } from "./runs.js";
+setRunSynthesisOutcome, queryRun, queryActiveRun, queryNonTerminalRunsByAnalysis, queryRunsForInspection, queryRunsByAnalysis, queryRunsByThread, } from "./runs.js";
 export { insertStepExecution, seedStepExecutions, sweepPendingStepExecutions, updateStepExecution, queryStepsByRun } from "./step-executions.js";
 export { setSandboxRef, setActiveExecId, clearSandboxRef, queryActiveSandboxes, reconcileReapedSandbox } from "./active-sandboxes.js";
 export { insertPlan, upsertPlan, loadPlan } from "./plans.js";
-export { tryStartDataProfile, tryRetryDataProfile, tryRerunDataProfile, completeDataProfile, failDataProfile, expireStaleDataProfile, reconcileOrphanedDataProfile, clearDataProfile, loadDataProfileStatus, loadSeedInputFileIds, } from "./data-profile.js";
+export { tryStartDataProfile, tryRetryDataProfile, tryRerunDataProfile, completeDataProfile, failDataProfile, expireStaleDataProfile, reconcileOrphanedDataProfile, clearDataProfile, loadDataProfileStatus, loadSeedInputFileIds, recordDataProfileWorkflowId, } from "./data-profile.js";
 export { queryRunCountsByAnalyses, queryThreadCountsByAnalyses, queryDataProfileStatusByAnalyses } from "./analyses-metrics.js";
 export { AnalysisStateRowSchema, ArtifactRole, ArtifactRowSchema, RunStatus, StepExecutionStatus, SynthesisStatus, CortexRunRowSchema, StepExecutionRowSchema, CortexPlanRowSchema, } from "./schema.js";
 export { insertAssessment, updateProgress, setDossier, markFailed, getAssessment, listAssessmentsByOrg, softDeleteAssessment, TargetAssessmentStatusSchema, TargetAssessmentErrorSchema, TargetAssessmentRowSchema, } from "./target-assessments.js";

package/dist/state/init.js

@@ -27,10 +27,22 @@ CREATE TABLE IF NOT EXISTS cortex_analysis_state (
   data_profile_started_at   TEXT,
   data_profile_completed_at TEXT,
   data_profile_result       JSONB,
+  data_profile_workflow_id  TEXT,
   created_at                TEXT NOT NULL,
   updated_at                TEXT NOT NULL
 );
 
+-- DBOS workflow id of the profile attempt that owns the row — what a consumer
+-- subscribes to in order to observe that profile's activity. Written by the
+-- workflow body, not the trigger: the ledger claim happens before the workflow id
+-- is minted, so only the body knows the id of the attempt that actually started.
+-- Nullable, and absence is a normal state rather than a defect, with two ordinary
+-- causes: a row claimed whose body has not yet recorded its id, and a row written
+-- before this column existed. Both mean "this profile's stream is not
+-- addressable", which is true in each case — hence no backfill.
+ALTER TABLE cortex_analysis_state
+  ADD COLUMN IF NOT EXISTS data_profile_workflow_id TEXT;
+
 -- File registry — artifact_id (provenance) + file_id (S3), cross-run.
 CREATE TABLE IF NOT EXISTS cortex_artifacts (
   analysis_id   TEXT NOT NULL,
@@ -207,12 +219,20 @@ CREATE INDEX IF NOT EXISTS idx_cortex_regulatory_chunks_metadata
 -- workflow and sandbox agent loops use the DBOS step cache, never this
 -- table (see the harness-thread-store spec). The (thread_id, seq) primary key already serves
 -- (thread_id, seq DESC) reads, so no separate index is needed.
+--
+-- message_envelope is JSON, not JSONB, and must stay that way. JSONB stores a
+-- re-sorted parse tree rather than the document it was given, so a tool call's
+-- input — and every other free-form payload, which has no schema to be
+-- normalized back against on read — comes back key-reordered. Those bytes are
+-- re-sent to the provider on the next turn, where a reordered prefix misses the
+-- prompt cache. JSON stores the text verbatim. Nothing indexes this column, and
+-- the JSON operators retractLastTurn uses work the same on either type.
 CREATE TABLE IF NOT EXISTS messages (
   thread_id     TEXT NOT NULL,
   seq           BIGINT NOT NULL,
   role          TEXT,
   content_jsonb JSONB,
-  message_envelope JSONB,
+  message_envelope JSON,
   tokens        INTEGER NOT NULL,
   created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
   PRIMARY KEY (thread_id, seq)
@@ -411,7 +431,22 @@ export async function initCortexState(pool, injected) {
                 // carry the NOT NULL floor, which would reject a clear. Idempotent:
                 // dropping an absent NOT NULL no-ops, so this is a no-op on fresh DBs.
                 "ALTER TABLE cortex_analysis_state ALTER COLUMN data_profile_status DROP NOT NULL",
-                "ALTER TABLE messages ADD COLUMN IF NOT EXISTS message_envelope JSONB",
+                "ALTER TABLE messages ADD COLUMN IF NOT EXISTS message_envelope JSON",
+                // Demote an existing JSONB envelope column to JSON (see the CREATE
+                // TABLE comment). Type-guarded because ALTER ... TYPE rewrites the
+                // whole table and this runs at every boot; scoped to
+                // current_schema() so parallel test schemas never see each other.
+                // Rows already written as JSONB carry over as they stand — their
+                // original key order is not recoverable.
+                `DO $$ BEGIN
+                  IF EXISTS (
+                    SELECT 1 FROM information_schema.columns
+                    WHERE table_schema = current_schema() AND table_name = 'messages'
+                      AND column_name = 'message_envelope' AND data_type = 'jsonb'
+                  ) THEN
+                    ALTER TABLE messages ALTER COLUMN message_envelope TYPE JSON USING message_envelope::text::json;
+                  END IF;
+                END $$`,
                 // Grant key an 'always' records the standing grant under. Nullable
                 // and unbackfilled: every new row writes it (command when absent), and
                 // orphaned legacy pending rows are swept to 'expired' before any answer

package/dist/state/runs.d.ts

@@ -26,6 +26,11 @@ export interface RunReservation {
     readonly row: CortexRunRow;
     readonly inserted: boolean;
 }
+/** Bounded run rows paired with the true count before limit/offset. */
+export interface RunPage {
+    readonly runs: CortexRunRow[];
+    readonly total: number;
+}
 export declare class RunIdentityCollisionError extends Error {
     readonly runId: string;
     constructor(runId: string);
@@ -59,6 +64,24 @@ export declare function reserveRunById(pool: Querier, input: InsertRunInput): Re
  * most one match.
  */
 export declare function queryActiveRun(pool: Querier, analysisId: string, planId: string | null): ResultAsync<CortexRunRow | null, DbError>;
+/**
+ * Every NON-TERMINAL run of an analysis, newest-first and deliberately unbounded.
+ *
+ * The counterpart to {@link queryRunsByAnalysis}, which answers "the newest N runs" — a windowed
+ * question, and the wrong one for a host driving live surfaces. Ordering by `started_at DESC` and
+ * capping means the run most worth watching is the first to fall out: a long analysis still going
+ * while ten short ones start and finish after it leaves the window entirely, so a host reading only
+ * that window loses its progress AND never learns it terminated.
+ *
+ * Unbounded is safe here in a way it is not for the general listing: this result is capped by the
+ * analysis's live concurrency, not by its history, and a run leaves the set permanently when it
+ * finishes.
+ *
+ * The status set is the one {@link queryActiveRun} uses — non-terminal means still running, or
+ * suspended awaiting funds. Keep the two in step: a new non-terminal status added to one and not the
+ * other makes a live run invisible to exactly one of its readers.
+ */
+export declare function queryActiveRunsByAnalysis(pool: Querier, analysisId: string): ResultAsync<CortexRunRow[], DbError>;
 export declare function updateRunStatus(pool: Querier, runId: string, status: "running" | "completed" | "partial" | "failed" | "canceled" | "suspended_insufficient_funds", error?: string | null): ResultAsync<void, DbError>;
 export declare function promoteFailedToPartial(pool: Querier, runId: string): ResultAsync<boolean, DbError>;
 export declare function queryRun(pool: Querier, runId: string): ResultAsync<CortexRunRow | null, DbError>;
@@ -66,6 +89,22 @@ export declare function queryRunsByAnalysis(pool: Querier, analysisId: string, {
     limit?: number;
     offset?: number;
 }): ResultAsync<CortexRunRow[], DbError>;
+/**
+ * Read the analysis's non-terminal run activity without coupling it to a
+ * conversation thread. The total is counted before the detail limit so a
+ * bounded prompt projection can disclose omitted rows.
+ */
+export declare function queryNonTerminalRunsByAnalysis(pool: Querier, analysisId: string, limit?: number): ResultAsync<RunPage, DbError>;
+/**
+ * Read one stable inspection page: running first, then suspended, then
+ * terminal history. This is deliberately separate from
+ * {@link queryRunsByAnalysis}, whose chronological order is an embedder/UI
+ * contract.
+ */
+export declare function queryRunsForInspection(pool: Querier, analysisId: string, { limit, offset }?: {
+    limit?: number;
+    offset?: number;
+}): ResultAsync<RunPage, DbError>;
 export declare function queryRunsByThread(pool: Querier, analysisId: string, threadId: string, { limit, offset }?: {
     limit?: number;
     offset?: number;

package/dist/state/runs.js

@@ -139,6 +139,38 @@ export function queryActiveRun(pool, analysisId, planId) {
         return row ? mapRunRow(row) : null;
     });
 }
+/**
+ * Every NON-TERMINAL run of an analysis, newest-first and deliberately unbounded.
+ *
+ * The counterpart to {@link queryRunsByAnalysis}, which answers "the newest N runs" — a windowed
+ * question, and the wrong one for a host driving live surfaces. Ordering by `started_at DESC` and
+ * capping means the run most worth watching is the first to fall out: a long analysis still going
+ * while ten short ones start and finish after it leaves the window entirely, so a host reading only
+ * that window loses its progress AND never learns it terminated.
+ *
+ * Unbounded is safe here in a way it is not for the general listing: this result is capped by the
+ * analysis's live concurrency, not by its history, and a run leaves the set permanently when it
+ * finishes.
+ *
+ * The status set is the one {@link queryActiveRun} uses — non-terminal means still running, or
+ * suspended awaiting funds. Keep the two in step: a new non-terminal status added to one and not the
+ * other makes a live run invisible to exactly one of its readers.
+ */
+export function queryActiveRunsByAnalysis(pool, analysisId) {
+    return tryQuery("runs.queryActiveRunsByAnalysis", async () => {
+        const result = await pool.query({
+            text: `SELECT run_id, analysis_id, thread_id, workflow_name,
+                   status, started_at, completed_at, error, synthesis_status, synthesis_reason, parts,
+                   mandate_jti, mandate_expires_at, plan_id -- oss-core-managed-ok: run-mandate ledger (nullable; OSS leaves null)
+            FROM cortex_runs
+            WHERE analysis_id = $1
+              AND status IN ('running','suspended_insufficient_funds')
+            ORDER BY started_at DESC`,
+            values: [analysisId],
+        });
+        return result.rows.map(mapRunRow);
+    });
+}
 export function updateRunStatus(pool, runId, status, error) {
     const now = new Date().toISOString();
     const isTerminal = status === "completed" || status === "partial" || status === "failed" || status === "canceled";
@@ -189,6 +221,77 @@ export function queryRunsByAnalysis(pool, analysisId, { limit = 50, offset = 0 }
         return result.rows.map(mapRunRow);
     });
 }
+/**
+ * Read the analysis's non-terminal run activity without coupling it to a
+ * conversation thread. The total is counted before the detail limit so a
+ * bounded prompt projection can disclose omitted rows.
+ */
+export function queryNonTerminalRunsByAnalysis(pool, analysisId, limit = 20) {
+    return tryQuery("runs.queryNonTerminalRunsByAnalysis", async () => {
+        const countResult = await pool.query({
+            text: `SELECT COUNT(*)::int AS total
+            FROM cortex_runs
+            WHERE analysis_id = $1
+              AND status IN ('running','suspended_insufficient_funds')`,
+            values: [analysisId],
+        });
+        const rowsResult = await pool.query({
+            text: `SELECT run_id, analysis_id, thread_id, workflow_name,
+                   status, started_at, completed_at, error, synthesis_status, synthesis_reason, parts,
+                   mandate_jti, mandate_expires_at, plan_id
+            FROM cortex_runs
+            WHERE analysis_id = $1
+              AND status IN ('running','suspended_insufficient_funds')
+            ORDER BY CASE status
+                         WHEN 'running' THEN 0
+                         WHEN 'suspended_insufficient_funds' THEN 1
+                         ELSE 2
+                     END,
+                     started_at DESC,
+                     run_id DESC
+            LIMIT $2`,
+            values: [analysisId, limit],
+        });
+        return {
+            runs: rowsResult.rows.map(mapRunRow),
+            total: Number(countResult.rows[0]?.total ?? 0),
+        };
+    });
+}
+/**
+ * Read one stable inspection page: running first, then suspended, then
+ * terminal history. This is deliberately separate from
+ * {@link queryRunsByAnalysis}, whose chronological order is an embedder/UI
+ * contract.
+ */
+export function queryRunsForInspection(pool, analysisId, { limit = 50, offset = 0 } = {}) {
+    return tryQuery("runs.queryRunsForInspection", async () => {
+        const countResult = await pool.query({
+            text: "SELECT COUNT(*)::int AS total FROM cortex_runs WHERE analysis_id = $1",
+            values: [analysisId],
+        });
+        const rowsResult = await pool.query({
+            text: `SELECT run_id, analysis_id, thread_id, workflow_name,
+                   status, started_at, completed_at, error, synthesis_status, synthesis_reason, parts,
+                   mandate_jti, mandate_expires_at, plan_id
+            FROM cortex_runs
+            WHERE analysis_id = $1
+            ORDER BY CASE status
+                         WHEN 'running' THEN 0
+                         WHEN 'suspended_insufficient_funds' THEN 1
+                         ELSE 2
+                     END,
+                     started_at DESC,
+                     run_id DESC
+            LIMIT $2 OFFSET $3`,
+            values: [analysisId, limit, offset],
+        });
+        return {
+            runs: rowsResult.rows.map(mapRunRow),
+            total: Number(countResult.rows[0]?.total ?? 0),
+        };
+    });
+}
 export function queryRunsByThread(pool, analysisId, threadId, { limit = 50, offset = 0 } = {}) {
     return tryQuery("runs.queryRunsByThread", async () => {
         const result = await pool.query({

package/dist/tasks/data-profile-activity.d.ts

@@ -0,0 +1,87 @@
+/**
+ * The data-profile workflow's activity emissions, as a pure factory over a raw
+ * stream write.
+ *
+ * Extracted from the workflow body for the same reason `createLineageCollector`
+ * and `buildDriftSignature` are: a DBOS workflow body is not reachable from a
+ * unit test — it needs a launched engine, a sandbox, a scripted model, and an
+ * embedder — so the decidable part is lifted out and tested on its own. What is
+ * decidable here is the whole observable contract of this capability: which
+ * phase each moment of a profile reports, and in what words. Those phrases are
+ * what a user reads, so they are the one part of the work that must not be left
+ * to drift.
+ *
+ * What stays in the body is only control flow — where each call sits relative to
+ * the ledger writes. That is not extractable, and the ordering property it
+ * carries (exactly one terminal emission) is guaranteed structurally instead:
+ * there is exactly one `complete` call site and it is the last statement of the
+ * success path, after the terminal ledger write and the authorization revoke, so
+ * anything that throws on the way there reaches the failure path having emitted
+ * no terminal at all.
+ */
+import type { Logger } from "../lib/logger.js";
+/**
+ * Writes one part to the run-event stream. Injected rather than imported so this
+ * module stays free of the durability engine and so a test can record what a
+ * profile would have reported without launching one.
+ */
+export type ActivityWrite = (part: unknown) => Promise<void>;
+/**
+ * The profile's activity channel. One method per moment the body reports, rather
+ * than a generic `emit(phase, text)`: the phrases are normative, and a call site
+ * that passes its own string is a call site that can drift from the spec.
+ *
+ * Every method resolves even when the underlying write fails — see
+ * {@link createProfileActivityEmitter}.
+ *
+ * Five of the contract's phases have no method here, and their absence is a
+ * decision rather than an oversight: `generating-metadata` and
+ * `generating-summary` describe the sandbox-step's post-agent pipeline, which a
+ * profile does not run (its agent delivers everything through `submit_profile`);
+ * `persisting` is defined as step bytes uploading to an artifact store, and a
+ * profile's durable products are the vector index and the ledger row, so it would
+ * describe nothing; `retrying` needs a retry loop, and a profile failure is
+ * terminal with recovery being a fresh attempt; `warning` needs a non-fatal
+ * user-facing warning channel, and the body's two soft conditions (an empty
+ * manifest, a fallback file description) are logged because neither warrants
+ * interrupting the activity line.
+ */
+export interface ProfileActivityEmitter {
+    /** Reported before the sandbox is created — the longest wait in a profile, and the one that precedes the agent entirely. */
+    sandboxInit(): Promise<void>;
+    /** Reported once the sandbox is ready, covering the gap before the agent's first tool call. */
+    agentStarting(): Promise<void>;
+    /** Reported per tool call the profiler agent makes, phrased by the shared translator. */
+    forTool(name: string, input: unknown): Promise<void>;
+    /** Reported for the vector-store pass that indexes per-file descriptions. */
+    indexing(): Promise<void>;
+    /** The success terminal. Emitted only after the terminal ledger write has landed. */
+    complete(): Promise<void>;
+    /** The failure terminal, carrying the same user-safe reason the ledger receives. */
+    failed(reason: string): Promise<void>;
+}
+/** Identity the emitted parts carry — the workflow's synthetic frame, not a real run. */
+export interface ProfileActivityFrame {
+    /**
+     * The constant literal the data-profile workflow uses as its run id. It is the
+     * same string for every analysis, so it identifies nothing; consumers are
+     * required not to key on it (see the data-profile-observation spec). It is
+     * carried because the part contract requires the field and because this is the
+     * frame the workflow already uses for its sandbox identity and scratch path.
+     */
+    readonly runId: string;
+    /** The constant literal step id of the profile's single synthetic step. */
+    readonly stepId: string;
+}
+/**
+ * Build the profile's activity channel over `write`.
+ *
+ * Every emission is awaited by its caller in body order, because `DBOS.writeStream`
+ * allocates a function id and an unawaited write would race the next real operation
+ * for the counter, desynchronising the recorded sequence on replay.
+ *
+ * A failing write is swallowed and logged, never propagated: observation is a
+ * diagnostic channel, and a dropped frame must not fail a profile that is otherwise
+ * succeeding. This mirrors the sandbox-step producer's stance on the same write.
+ */
+export declare function createProfileActivityEmitter(write: ActivityWrite, frame: ProfileActivityFrame, logger: Logger): ProfileActivityEmitter;

package/dist/tasks/data-profile-activity.js

@@ -0,0 +1,56 @@
+/**
+ * The data-profile workflow's activity emissions, as a pure factory over a raw
+ * stream write.
+ *
+ * Extracted from the workflow body for the same reason `createLineageCollector`
+ * and `buildDriftSignature` are: a DBOS workflow body is not reachable from a
+ * unit test — it needs a launched engine, a sandbox, a scripted model, and an
+ * embedder — so the decidable part is lifted out and tested on its own. What is
+ * decidable here is the whole observable contract of this capability: which
+ * phase each moment of a profile reports, and in what words. Those phrases are
+ * what a user reads, so they are the one part of the work that must not be left
+ * to drift.
+ *
+ * What stays in the body is only control flow — where each call sits relative to
+ * the ledger writes. That is not extractable, and the ordering property it
+ * carries (exactly one terminal emission) is guaranteed structurally instead:
+ * there is exactly one `complete` call site and it is the last statement of the
+ * success path, after the terminal ledger write and the authorization revoke, so
+ * anything that throws on the way there reaches the failure path having emitted
+ * no terminal at all.
+ */
+import { activityForTool, stepPartId } from "../sandbox/sandbox-step-translate.js";
+/**
+ * Build the profile's activity channel over `write`.
+ *
+ * Every emission is awaited by its caller in body order, because `DBOS.writeStream`
+ * allocates a function id and an unawaited write would race the next real operation
+ * for the counter, desynchronising the recorded sequence on replay.
+ *
+ * A failing write is swallowed and logged, never propagated: observation is a
+ * diagnostic channel, and a dropped frame must not fail a profile that is otherwise
+ * succeeding. This mirrors the sandbox-step producer's stance on the same write.
+ */
+export function createProfileActivityEmitter(write, frame, logger) {
+    // One reconciling id for the profile's single step, so the run-stream fold
+    // collapses every phase transition latest-wins onto one frame rather than
+    // accumulating them. Minted through the shared construction because that
+    // sameness across producers is what makes the fold correct.
+    const id = stepPartId("step-activity", frame.runId, frame.stepId);
+    const emit = async (phase, activity) => {
+        try {
+            await write({ type: "data-step-activity", id, runId: frame.runId, stepId: frame.stepId, phase, activity });
+        }
+        catch (err) {
+            logger.warn("run-event write failed (non-fatal)", { phase, ...logger.errorFields(err) });
+        }
+    };
+    return {
+        sandboxInit: () => emit("sandbox-init", "Starting sandbox"),
+        agentStarting: () => emit("executing", "Running data-profiler"),
+        forTool: (name, input) => emit("executing", activityForTool(name, input)),
+        indexing: () => emit("indexing", "Indexing input descriptions for search"),
+        complete: () => emit("complete", "Profile complete"),
+        failed: (reason) => emit("failed", reason),
+    };
+}

package/dist/tasks/data-profile.js

@@ -33,7 +33,8 @@ import { generateExecutionId } from "../sandbox/execution-id.js";
 import { mintSandboxIdentity } from "../sandbox/identity.js";
 import { createVectorStore } from "../state/vector-store.js";
 import { ProfilerOutputSchema } from "../schemas/data-profile-schemas.js";
-import { completeDataProfile, failDataProfile, loadDataProfileStatus, loadSeedInputFileIds, tryRerunDataProfile, tryStartDataProfile, upsertArtifacts, } from "../state/index.js";
+import { completeDataProfile, failDataProfile, loadDataProfileStatus, loadSeedInputFileIds, recordDataProfileWorkflowId, tryRerunDataProfile, tryStartDataProfile, upsertArtifacts, } from "../state/index.js";
+import { createProfileActivityEmitter } from "./data-profile-activity.js";
 import { ensureSearchIndex, searchIndexName } from "../workspace/search-config.js";
 /** Synthetic run/step literal for the data-profile workflow. */
 const DATA_PROFILE_RUN_LITERAL = "data-profile";
@@ -135,7 +136,29 @@ export async function runDataProfileBody(input, deps) {
     // Cortex-owned and must be revoked here.
     const { analysisId, runSession, ownsMandate = true, stagedInputs } = input; // oss-core-managed-ok
     const authorization = { runSession, ownsMandate }; // oss-core-managed-ok
+    // The profile's activity channel. `DBOS.writeStream` is body-only, so the write is bound here
+    // while every phase and phrase lives in the emitter — the phrases are the observable contract of
+    // this capability, and a body that composed its own strings is a body they can drift from.
+    // The frame is the workflow's synthetic one: both values are constants shared by every analysis,
+    // so they identify nothing and consumers are required not to key on them.
+    const activity = createProfileActivityEmitter((part) => DBOS.writeStream("events", part), { runId: DATA_PROFILE_RUN_LITERAL, stepId: DATA_PROFILE_STEP_LITERAL }, logger);
     try {
+        // Record which workflow owns this profile before anything else, so a consumer that resolves
+        // the id from the ledger can subscribe from the earliest possible moment. Guarded on a real
+        // ambient id: this body is also driven directly (outside a workflow), where the synthetic
+        // fallback used further down names no workflow at all and must never reach the ledger.
+        const ownWorkflowId = DBOS.workflowID;
+        if (ownWorkflowId !== undefined) {
+            await DBOS.runStep(async () => {
+                // A refused CAS is a normal in-band outcome, not a failure: the row left
+                // `running` underneath us (cleared, or stale-expired and re-claimed), which is
+                // the ledger correctly moving on. There is nothing to repair, and the profile's
+                // own work is unaffected — only its observability is.
+                if (!unwrapOrThrow(await recordDataProfileWorkflowId(deps.pool, analysisId, ownWorkflowId))) {
+                    logger.warn("workflow-id record skipped: ledger row not running (cleared or re-claimed concurrently)");
+                }
+            }, { name: "record-workflow-id" });
+        }
         // 1. Input files are already staged under data/inputs/ (see the data-profile-init spec); the
         // embedder populated the tree and handed us this manifest in the workflow
         // input. The body never downloads.
@@ -144,6 +167,9 @@ export async function runDataProfileBody(input, deps) {
             if (!unwrapOrThrow(await completeDataProfile(deps.pool, analysisId)))
                 logTerminalNoop(logger, analysisId, "completion");
             await deps.runAuthorizer.revoke(authorization, "data-profile-completed");
+            // This is a terminal completion like any other, so it reports one — a consumer watching
+            // an empty-manifest profile sees it settle rather than seeing the stream simply stop.
+            await activity.complete();
             return;
         }
         // 2. Register staged files in cortex_artifacts
@@ -193,6 +219,11 @@ export async function runDataProfileBody(input, deps) {
             `All file paths in your response must be relative to the analysis root and must EXACTLY match the paths listed above.`,
         ].join("\n");
         logger.info("starting sandbox", { executionId });
+        // Reported BEFORE the container exists, deliberately: provisioning is the longest single
+        // operation in a profile and it precedes the agent entirely, so a body that reported only
+        // from the agent loop would leave the longest wait of all unreported — the same defect the
+        // run panel's activity readout was built to remove.
+        await activity.sandboxInit();
         const sandbox = await deps.sandboxClient.createSandbox({
             runId: DATA_PROFILE_RUN_LITERAL,
             stepId: DATA_PROFILE_STEP_LITERAL,
@@ -247,13 +278,27 @@ export async function runDataProfileBody(input, deps) {
             const baseAgent = createDataProfilerAgent(sandboxAgentDeps);
             const agentDef = { ...baseAgent, tools: [...baseAgent.tools, submitProfileTool] };
             const signal = new AbortController().signal;
+            // Covers the gap between a ready sandbox and the agent's first tool call, which would
+            // otherwise still read as `Starting sandbox` long after the container was up. The run
+            // path's `Running ${agentId}` serves the same purpose at the same point.
+            await activity.agentStarting();
             await runToTerminal(agentDef, [{ role: "user", content: prompt }], childSession, {
                 provider: deps.provider,
                 signal,
-                emit: () => { },
+                // Every tool call the profiler makes becomes live activity. Only `tool-started`
+                // is forwarded: the loop's other events (iteration boundaries, model deltas,
+                // tool completions) describe machinery rather than work, and the panel this
+                // feeds carries a single line whose value is that it always names what is
+                // happening now. Awaited in body order, because `DBOS.writeStream` allocates a
+                // function id and an unawaited write would race the next operation for the
+                // counter and desynchronise the recorded sequence on replay.
+                emit: async (event) => {
+                    if (event.type === "tool-started")
+                        await activity.forTool(event.name, event.input);
+                },
                 runStep: durableStep,
-            }, {
                 resolved: () => capturedProfile !== null,
+            }, {
                 tools: [submitProfileTool],
                 nudge: "You stopped without calling submit_profile, so no profile was " +
                     "recorded. Call submit_profile now with structured metadata for " +
@@ -264,6 +309,11 @@ export async function runDataProfileBody(input, deps) {
             }
             const profilerData = capturedProfile;
             // 4. Index into vector store — real files only, consistent type metadata
+            //
+            // Reported as `indexing`, not `persisting`: the contract defines `persisting` as step
+            // bytes uploading to an artifact store, and a profile uploads nothing — its durable
+            // products are this vector index and the ledger row.
+            await activity.indexing();
             const profilerByPath = new Map(profilerData.files.map((f) => [f.path, f]));
             const normPath = (p) => p
                 .replace(/\/+/g, "/")
@@ -326,6 +376,13 @@ export async function runDataProfileBody(input, deps) {
                 logTerminalNoop(logger, analysisId, "completion");
             }
             await deps.runAuthorizer.revoke(authorization, "data-profile-completed");
+            // LAST statement of the success path, and that placement is the guarantee that exactly
+            // one terminal activity is ever emitted. Everything that could still throw — the ledger
+            // write above, the revoke — is already behind us, so any failure on the way here reaches
+            // the catch having emitted no terminal at all and reports `failed` alone. Emitted any
+            // earlier, a failing write would produce BOTH terminals and leave the fold's winner
+            // decided by arrival order. The sandbox teardown below emits nothing for the same reason.
+            await activity.complete();
         }
         finally {
             try {
@@ -338,9 +395,14 @@ export async function runDataProfileBody(input, deps) {
     }
     catch (err) {
         logger.error("profile failed", logger.errorFields(err));
-        if (!unwrapOrThrow(await failDataProfile(deps.pool, analysisId, profileFailureReason(err))))
+        const reason = profileFailureReason(err);
+        if (!unwrapOrThrow(await failDataProfile(deps.pool, analysisId, reason)))
             logTerminalNoop(logger, analysisId, "failure");
         await deps.runAuthorizer.revoke(authorization, "data-profile-failed");
+        // The same bounded, user-safe line the ledger receives — never the raw error, whose paths and
+        // stack frames stay in the log record above. This is the only other terminal emission, so
+        // reaching it means the success path did not emit one.
+        await activity.failed(reason);
     }
 }
 /**

package/dist/tools/bio/chembl.d.ts

@@ -28,7 +28,7 @@ export type ChemblOutput = {
     readonly targets: ChemblTarget[];
 };
 export declare const chemblTool: import("../define-tool.js").Tool<{
-    action: "targets" | "drug" | "compounds" | "mechanism" | "bioactivity";
+    action: "drug" | "targets" | "compounds" | "mechanism" | "bioactivity";
     query?: string | undefined;
     searchType?: "target" | "smiles" | "compound" | undefined;
     chemblId?: string | undefined;