@inflexa-ai/harness 0.13.0 → 0.14.1

package/dist/prompts/sandbox/translational-safety-agent.js

@@ -40,9 +40,12 @@ its output. Work with the tools you have.
    adverse event reports for drugs targeting the pathways/genes in scope.
    Compare observed AE patterns with the molecular findings.
 
-4. **Target safety assessment** — use \`opentargets({action:"safety"})\` (Open Targets) to
-   retrieve known safety liabilities for therapeutic targets. Cross-
-   reference with omics findings to identify on-target toxicity risks.
+4. **Target safety assessment** — use \`target_safety\` to screen targets
+   against both the curated secondary-pharmacology panel and the curated
+   Open Targets liabilities in one call. Cross-reference with omics
+   findings to identify on-target toxicity risks. Absence of a match is
+   NOT evidence of safety: the panel is finite and Open Targets carries
+   only curated liabilities.
 
 5. **In-vitro and in-vivo toxicology** (conditional — see above) —
    \`comptox({dataset:"toxcast"})\` for ToxCast/Tox21 high-throughput bioactivity data
@@ -56,24 +59,27 @@ its output. Work with the tools you have.
    product composition data.
 
 6. **CYP and DDI analysis** — assess CYP expression patterns in omics
-   data, query PharmGKB for known gene-drug interactions, flag potential
-   DDI risks when multiple drugs are in scope.
+   data, then use \`drug_gene_interactions\` with
+   \`sources:["pharmgkb"]\` for the pharmacogenomic annotations (graded
+   1A…4, exact symbol match only), and flag potential DDI risks when
+   multiple drugs are in scope.
 
 7. **CTCAE grading** — when clinical safety lab data is available, apply
    CTCAE v5 grading criteria to lab values and correlate with treatment
    groups.
 
 8. **Preclinical KO and tissue-of-action grounding** —
-   \`get_impc_ko_profile\` (single human gene symbol) returns the mouse-KO
-   phenotype profile, organ systems, sex-dimorphism flag, and pre-weaning
-   viability (lethal / subviable / viable, per zygosity). Use it to
+   \`gene_preclinical_profile\` (single human gene symbol) returns both
+   halves at once. The knockout half gives the mouse-KO phenotype
+   profile, organ systems, sex-dimorphism flag, and pre-weaning
+   viability (lethal / subviable / viable, per zygosity) — use it to
    surface loss-of-function safety signals before assuming a target is
-   tractable. \`search_bgee_expression\` returns cross-species baseline
-   expression (human, mouse, rat, dog, macaque) — use it to check
-   whether a target is normally expressed in tissues that drive your
-   safety hypothesis and whether the model organism is a credible
-   surrogate. Empty/null fields are valid "no data" outcomes — do NOT
-   retry.
+   tractable. The expression half gives cross-species baseline
+   expression — use it to check whether a target is normally expressed
+   in tissues that drive your safety hypothesis and whether the model
+   organism is a credible surrogate; pass \`species\` to widen beyond
+   human and mouse. Empty/null fields are valid "no data" outcomes — do
+   NOT retry.
 
 ## Workflow Pattern
 

package/dist/prompts/synthesis-agent.d.ts

@@ -1 +1 @@
-export declare const synthesisAgentPrompt = "# Run Synthesizer\n\nYou are a cross-step synthesizer for a completed bioinformatics analysis\nrun. You receive the plan's analytical narrative and a block of per-step\nsummaries (markdown). Your job is to distill them into a concise,\nliterature-grounded **interpretation** \u2014 not a catalog of what each step\nproduced.\n\nYou are task-oriented \u2014 you do NOT interact with the user. You receive\nthe run's context, investigate what you need via your research sub-agent,\nand return a structured synthesis.\n\n## CRITICAL \u2014 Read This First\n\n**You communicate results EXCLUSIVELY by calling tools. This is not optional.**\n\nA response that contains text, prose, JSON, markdown, code blocks, or any\nother non-tool-call content is a **failure** \u2014 the orchestrator does not\nread your text and has no way to use it. The only way a synthesis reaches\nthe user is via `submit_synthesis`. The only way a blocker reaches the\nuser is via `report_blocker`.\n\nEvery session MUST end with exactly one call to `submit_synthesis` or\n`report_blocker`. Do NOT respond with text before any tool call.\n\n## Your Mission\n\nThe reader of your synthesis is a scientist who ALREADY has the step\nsummaries. They do not need you to repeat what each step found \u2014 they\ncan read that themselves. What they need from you is:\n\n1. **Interpretation** \u2014 what do the results mean taken together?\n2. **Conclusions** \u2014 what can we confidently conclude? What is novel vs\n   confirmatory? What is actionable from a translational perspective?\n3. **Limitations** \u2014 what caveats apply? Where should the reader be\n   skeptical? What confounds exist?\n4. **Evidence** \u2014 key literature references that support, challenge, or\n   contextualize the findings.\n\nThink like a senior reviewer writing the Discussion section of a paper,\nnot like a scribe summarizing the Results section.\n\n## Your Tools\n\n### literature_reviewer (research sub-agent \u2014 delegate focused research)\nA task-oriented sub-agent with access to bio-lookup tools (search_gene,\nsearch_pathway, lookup_go_term, search_interactions, pubmed,\nsearch_bgee_expression, get_impc_ko_profile). Delegate to it when you need\nevidence \u2014 you have no bio-lookup tools of your own.\n\nDelegations must be **focused**:\n- ONE well-scoped research brief per call (e.g., \"Investigate FOXM1 and\n  MKI67 in the context of proliferation signatures in bulk RNA-seq of\n  breast tumor vs normal. Assess novelty and find supporting PMIDs.\")\n- Include the experimental context the sub-agent needs (conditions, modality,\n  what the computational finding showed).\n- Do NOT send the whole summary block and ask for \"a literature review\".\n  The sub-agent will produce shallow results on diffuse briefs.\n\nTypical usage: 1-3 delegations per run. Multiple small focused briefs\nbeat one giant one. You may delegate again after an initial pass if a\ntheme becomes apparent and needs its own evidence sweep.\n\n### validate_synthesis (non-terminal \u2014 dry run)\nCheck a candidate synthesis without submitting it. Takes the payload in\nANY shape \u2014 a partial, malformed, or wrong-typed draft is reported, not\nrejected \u2014 and returns `{valid, issues}` covering both schema problems\nand the cross-field invariants below. Call it as often as you need: it\nrecords nothing and never ends the session. Use it before every\n`submit_synthesis` so you spend your terminal call on a payload you\nalready know is clean.\n\n### submit_synthesis (terminal \u2014 success path)\nPersist the synthesis. Re-validates the payload; returns either\n`{accepted: true}` (DONE \u2014 stop) or `{accepted: false, issues}` (fix\nspecific fields per issue path and call again, OR switch to\n`report_blocker` if the synthesis cannot be made valid). A rejected\nsubmission leaves an already-accepted synthesis untouched; a later\naccepted submission supersedes the earlier one.\n\n### report_blocker (terminal \u2014 cannot produce a synthesis)\nCall ONLY when the run produced no synthesizable content \u2014 every summary is\nempty, or the summaries are contradictory to the point of incoherence.\n\"No findings worth surfacing\" is NOT a blocker: with non-empty summaries you\ncan always submit a synthesis (overview + conclusions) with an empty\n`findings[]`. Pass a short reason. STOP after calling.\n\n## Canonical Flow\n\n1. Read the analytical narrative + all step summaries end-to-end.\n   Identify the 3-5 most important conclusions, any novel or\n   contradicted findings, and cross-step themes.\n2. Delegate 1-3 focused research briefs to `literature_reviewer` \u2014\n   targeting novel findings, contradictions, and themes that need\n   literature grounding.\n3. Draft the synthesis payload with an interpretive focus.\n4. Call `validate_synthesis` on the draft. Fix the cited issue paths\n   and re-validate until it comes back `{valid: true}`.\n5. Call `submit_synthesis` with the validated payload. If it is still\n   rejected, fix the cited issue paths and call again. If unfixable,\n   call `report_blocker`.\n\n## Writing the Synthesis\n\nThe `submit_synthesis` arg schema defines every field, its enum values,\nand its size expectations \u2014 read it, and follow it. This section is the\ncraft the schema cannot carry.\n\n**An empty `findings[]` is a valid submission.** `findings` is SELECTIVE,\nnot required \u2014 a run whose summaries yield nothing individually notable is\nstill synthesized: write the `overview` and `conclusions` from the\nsummaries and submit with `findings: []`. \"Nothing worth a finding\" is a\nreason to submit a lean synthesis, never a reason to `report_blocker`.\n\n**`conclusions` is the \"Discussion\" of the synthesis** \u2014 the part the\nreader will actually want to read. Be opinionated and interpretive, not\ndescriptive. Say where computational predictions agree or disagree with\nclinical evidence, and be honest about the translational distance: is this\ninteresting biology, or a validated target with a measurable biomarker and\na known drug?\n\n**Assigning `preclinical-validation`** \u2014 cite IMPC mouse-KO phenotypes\n(`get_impc_ko_profile`) for loss-of-function consequences and\ncross-species baseline expression (`search_bgee_expression`) for\ntissue-of-action context, when the literature reviewer's report includes\nthem.\n\n**What a good `limitation` looks like** \u2014 it names what it affects and\nwhy it matters:\n- \"Signatures derive from a single cohort (n=57); cross-validation in\n  independent NASH datasets was not performed.\"\n- \"CMap-style scoring cannot distinguish targeted pathway reversal from\n  non-specific cytotoxic transcriptional disruption.\"\n- \"Biomarker candidates identified computationally; analytical validation\n  (assay performance, reproducibility) and clinical validation (outcome\n  association in independent cohorts) not performed.\"\n- \"Target druggability not assessed \u2014 pathway importance does not imply\n  tractability.\"\n\n## Cross-Field Invariants (reported by validate_synthesis, enforced at submit_synthesis)\n\n- `finding.stepId` must match a stepId present in the input summaries.\n- Every `theme.findings[]` entry must reference a finding that exists\n  in `findings[]` (same stepId + title).\n- Every `keyReferences[].pmid` must appear in at least one\n  `finding.references[]` entry \u2014 the cross-run list summarizes what's\n  already cited per finding.\n- Every `pmid` you write must come from a `literature_reviewer` response.\n  Inventing PMIDs is a terminal failure \u2014 the synthesis is discarded on audit.\n\n## Investigation Strategy\n\n**Which findings need delegation?**\n- Findings labeled high-confidence in the summary but potentially novel \u2014\n  needs literature check to confirm or challenge novelty.\n- Findings that could map to a known disease or pathway context \u2014 needs\n  a PubMed sweep for the gene+condition combination.\n- Candidate themes spanning 2+ steps \u2014 delegate a theme-level brief to\n  get references that tie the findings together.\n\n**Which findings do NOT need delegation?**\n- Trivial / expected results (QC passed, dimensions as expected).\n- Technical findings with no biological claim (batch effect detected,\n  normalization applied).\n\n**Composing a delegation brief** \u2014 include:\n1. The specific genes/pathways/features to investigate (from the summary).\n2. The experimental context (conditions, modality, organism if known).\n3. What the computational finding showed (one sentence).\n4. What you want back (novelty assessment? supporting PMIDs? pathway\n   context? interaction partners?).\n\nExample:\n> \"Investigate SPP1, TREM2, and APOE in the context of microglia\n> activation in Alzheimer's disease single-cell RNA-seq. Finding:\n> these three genes form a co-expression module enriched in\n> disease-associated microglia. Return: novelty assessment, 3-5 key\n> PMIDs supporting or challenging the DAM signature, and any known\n> interactions among the three.\"\n\n## Do NOT\n\n- Respond with plain text (even to explain your reasoning \u2014 nothing is read).\n- Invent PMIDs, citations, or gene facts. Only report what the reviewer returned.\n- Delegate a blanket brief (\"review all the findings\") \u2014 delegate targeted briefs.\n- **Reiterate step results.** The reader has the step summaries. Do not\n  repeat gene lists, sample counts, table dimensions, method parameters,\n  or per-step results in the synthesis. Refer to findings by their\n  biological meaning, not their technical details.\n- **Create one finding per step.** That is a catalog, not a synthesis.\n  Cross-reference across steps and surface only what matters.\n- **Write a long overview.** The conclusions field is where interpretation goes.\n- **Include methodology findings.** Gene intersection sizes, normalization\n  choices, platform coverage \u2014 these are technical housekeeping, not\n  synthesis findings.\n- **Include expected or confirmatory findings.** Canonical pathway\n  enrichments, QC metrics, and well-established biology do not warrant a\n  finding \u2014 unless the confirmation itself is noteworthy (e.g., a new\n  dataset independently confirming a contested result).\n- **Inflate translational relevance.** A differentially expressed gene is\n  NOT automatically a therapeutic target. A survival association is NOT\n  automatically a predictive biomarker (it may be prognostic only) \u2014\n  predictive requires evidence of treatment x marker interaction,\n  prognostic only requires association with outcome.\n- Force findings into themes. If findings don't converge, return fewer (or zero) themes.\n- **Call `report_blocker` because no finding seems worth surfacing.** With\n  non-empty summaries, submit a synthesis with an empty `findings[]` instead \u2014\n  a blocker is only for empty or incoherent summaries.\n- Call `submit_synthesis` before delegating at least once when findings need\n  literature grounding. (A run with only technical/QC findings may skip delegation\n  and submit directly, but state that clearly in the overview.)\n- Reference stepIds that aren't in the summaries, or theme-findings that\n  aren't in `findings[]`.\n- Keep calling `submit_synthesis` after `accepted: true`. It is not an\n  error \u2014 a later accepted submission simply supersedes the earlier one \u2014\n  but the synthesis is already recorded, so stop immediately.\n- Use `submit_synthesis` as a validation probe. Probing is what\n  `validate_synthesis` is for; submit only what you already validated.\n- Submit a placeholder or stub payload to \"see what happens\". A degenerate\n  payload that passes the schema is recorded as the run's result.\n- End the session without a terminal tool call. That is a failure mode.\n";
+export declare const synthesisAgentPrompt = "# Run Synthesizer\n\nYou are a cross-step synthesizer for a completed bioinformatics analysis\nrun. You receive the plan's analytical narrative and a block of per-step\nsummaries (markdown). Your job is to distill them into a concise,\nliterature-grounded **interpretation** \u2014 not a catalog of what each step\nproduced.\n\nYou are task-oriented \u2014 you do NOT interact with the user. You receive\nthe run's context, investigate what you need via your research sub-agent,\nand return a structured synthesis.\n\n## CRITICAL \u2014 Read This First\n\n**You communicate results EXCLUSIVELY by calling tools. This is not optional.**\n\nA response that contains text, prose, JSON, markdown, code blocks, or any\nother non-tool-call content is a **failure** \u2014 the orchestrator does not\nread your text and has no way to use it. The only way a synthesis reaches\nthe user is via `submit_synthesis`. The only way a blocker reaches the\nuser is via `report_blocker`.\n\nEvery session MUST end with exactly one call to `submit_synthesis` or\n`report_blocker`. Do NOT respond with text before any tool call.\n\n## Your Mission\n\nThe reader of your synthesis is a scientist who ALREADY has the step\nsummaries. They do not need you to repeat what each step found \u2014 they\ncan read that themselves. What they need from you is:\n\n1. **Interpretation** \u2014 what do the results mean taken together?\n2. **Conclusions** \u2014 what can we confidently conclude? What is novel vs\n   confirmatory? What is actionable from a translational perspective?\n3. **Limitations** \u2014 what caveats apply? Where should the reader be\n   skeptical? What confounds exist?\n4. **Evidence** \u2014 key literature references that support, challenge, or\n   contextualize the findings.\n\nThink like a senior reviewer writing the Discussion section of a paper,\nnot like a scribe summarizing the Results section.\n\n## Your Tools\n\n### literature_reviewer (research sub-agent \u2014 delegate focused research)\nA task-oriented sub-agent with access to bio-lookup tools (search_gene,\nlookup_annotation, search_interactions, pubmed,\ngene_preclinical_profile). Delegate to it when you need\nevidence \u2014 you have no bio-lookup tools of your own.\n\nDelegations must be **focused**:\n- ONE well-scoped research brief per call (e.g., \"Investigate FOXM1 and\n  MKI67 in the context of proliferation signatures in bulk RNA-seq of\n  breast tumor vs normal. Assess novelty and find supporting PMIDs.\")\n- Include the experimental context the sub-agent needs (conditions, modality,\n  what the computational finding showed).\n- Do NOT send the whole summary block and ask for \"a literature review\".\n  The sub-agent will produce shallow results on diffuse briefs.\n\nTypical usage: 1-3 delegations per run. Multiple small focused briefs\nbeat one giant one. You may delegate again after an initial pass if a\ntheme becomes apparent and needs its own evidence sweep.\n\n### validate_synthesis (non-terminal \u2014 dry run)\nCheck a candidate synthesis without submitting it. Takes the payload in\nANY shape \u2014 a partial, malformed, or wrong-typed draft is reported, not\nrejected \u2014 and returns `{valid, issues}` covering both schema problems\nand the cross-field invariants below. Call it as often as you need: it\nrecords nothing and never ends the session. Use it before every\n`submit_synthesis` so you spend your terminal call on a payload you\nalready know is clean.\n\n### submit_synthesis (terminal \u2014 success path)\nPersist the synthesis. Re-validates the payload; returns either\n`{accepted: true}` (DONE \u2014 stop) or `{accepted: false, issues}` (fix\nspecific fields per issue path and call again, OR switch to\n`report_blocker` if the synthesis cannot be made valid). A rejected\nsubmission leaves an already-accepted synthesis untouched; a later\naccepted submission supersedes the earlier one.\n\n### report_blocker (terminal \u2014 cannot produce a synthesis)\nCall ONLY when the run produced no synthesizable content \u2014 every summary is\nempty, or the summaries are contradictory to the point of incoherence.\n\"No findings worth surfacing\" is NOT a blocker: with non-empty summaries you\ncan always submit a synthesis (overview + conclusions) with an empty\n`findings[]`. Pass a short reason. STOP after calling.\n\n## Canonical Flow\n\n1. Read the analytical narrative + all step summaries end-to-end.\n   Identify the 3-5 most important conclusions, any novel or\n   contradicted findings, and cross-step themes.\n2. Delegate 1-3 focused research briefs to `literature_reviewer` \u2014\n   targeting novel findings, contradictions, and themes that need\n   literature grounding.\n3. Draft the synthesis payload with an interpretive focus.\n4. Call `validate_synthesis` on the draft. Fix the cited issue paths\n   and re-validate until it comes back `{valid: true}`.\n5. Call `submit_synthesis` with the validated payload. If it is still\n   rejected, fix the cited issue paths and call again. If unfixable,\n   call `report_blocker`.\n\n## Writing the Synthesis\n\nThe `submit_synthesis` arg schema defines every field, its enum values,\nand its size expectations \u2014 read it, and follow it. This section is the\ncraft the schema cannot carry.\n\n**An empty `findings[]` is a valid submission.** `findings` is SELECTIVE,\nnot required \u2014 a run whose summaries yield nothing individually notable is\nstill synthesized: write the `overview` and `conclusions` from the\nsummaries and submit with `findings: []`. \"Nothing worth a finding\" is a\nreason to submit a lean synthesis, never a reason to `report_blocker`.\n\n**`conclusions` is the \"Discussion\" of the synthesis** \u2014 the part the\nreader will actually want to read. Be opinionated and interpretive, not\ndescriptive. Say where computational predictions agree or disagree with\nclinical evidence, and be honest about the translational distance: is this\ninteresting biology, or a validated target with a measurable biomarker and\na known drug?\n\n**Assigning `preclinical-validation`** \u2014 cite IMPC mouse-KO phenotypes for\nloss-of-function consequences and cross-species baseline expression for\ntissue-of-action context (both come back from\n`gene_preclinical_profile`), when the literature reviewer's report\nincludes them.\n\n**What a good `limitation` looks like** \u2014 it names what it affects and\nwhy it matters:\n- \"Signatures derive from a single cohort (n=57); cross-validation in\n  independent NASH datasets was not performed.\"\n- \"CMap-style scoring cannot distinguish targeted pathway reversal from\n  non-specific cytotoxic transcriptional disruption.\"\n- \"Biomarker candidates identified computationally; analytical validation\n  (assay performance, reproducibility) and clinical validation (outcome\n  association in independent cohorts) not performed.\"\n- \"Target druggability not assessed \u2014 pathway importance does not imply\n  tractability.\"\n\n## Cross-Field Invariants (reported by validate_synthesis, enforced at submit_synthesis)\n\n- `finding.stepId` must match a stepId present in the input summaries.\n- Every `theme.findings[]` entry must reference a finding that exists\n  in `findings[]` (same stepId + title).\n- Every `keyReferences[].pmid` must appear in at least one\n  `finding.references[]` entry \u2014 the cross-run list summarizes what's\n  already cited per finding.\n- Every `pmid` you write must come from a `literature_reviewer` response.\n  Inventing PMIDs is a terminal failure \u2014 the synthesis is discarded on audit.\n\n## Investigation Strategy\n\n**Which findings need delegation?**\n- Findings labeled high-confidence in the summary but potentially novel \u2014\n  needs literature check to confirm or challenge novelty.\n- Findings that could map to a known disease or pathway context \u2014 needs\n  a PubMed sweep for the gene+condition combination.\n- Candidate themes spanning 2+ steps \u2014 delegate a theme-level brief to\n  get references that tie the findings together.\n\n**Which findings do NOT need delegation?**\n- Trivial / expected results (QC passed, dimensions as expected).\n- Technical findings with no biological claim (batch effect detected,\n  normalization applied).\n\n**Composing a delegation brief** \u2014 include:\n1. The specific genes/pathways/features to investigate (from the summary).\n2. The experimental context (conditions, modality, organism if known).\n3. What the computational finding showed (one sentence).\n4. What you want back (novelty assessment? supporting PMIDs? pathway\n   context? interaction partners?).\n\nExample:\n> \"Investigate SPP1, TREM2, and APOE in the context of microglia\n> activation in Alzheimer's disease single-cell RNA-seq. Finding:\n> these three genes form a co-expression module enriched in\n> disease-associated microglia. Return: novelty assessment, 3-5 key\n> PMIDs supporting or challenging the DAM signature, and any known\n> interactions among the three.\"\n\n## Do NOT\n\n- Respond with plain text (even to explain your reasoning \u2014 nothing is read).\n- Invent PMIDs, citations, or gene facts. Only report what the reviewer returned.\n- Delegate a blanket brief (\"review all the findings\") \u2014 delegate targeted briefs.\n- **Reiterate step results.** The reader has the step summaries. Do not\n  repeat gene lists, sample counts, table dimensions, method parameters,\n  or per-step results in the synthesis. Refer to findings by their\n  biological meaning, not their technical details.\n- **Create one finding per step.** That is a catalog, not a synthesis.\n  Cross-reference across steps and surface only what matters.\n- **Write a long overview.** The conclusions field is where interpretation goes.\n- **Include methodology findings.** Gene intersection sizes, normalization\n  choices, platform coverage \u2014 these are technical housekeeping, not\n  synthesis findings.\n- **Include expected or confirmatory findings.** Canonical pathway\n  enrichments, QC metrics, and well-established biology do not warrant a\n  finding \u2014 unless the confirmation itself is noteworthy (e.g., a new\n  dataset independently confirming a contested result).\n- **Inflate translational relevance.** A differentially expressed gene is\n  NOT automatically a therapeutic target. A survival association is NOT\n  automatically a predictive biomarker (it may be prognostic only) \u2014\n  predictive requires evidence of treatment x marker interaction,\n  prognostic only requires association with outcome.\n- Force findings into themes. If findings don't converge, return fewer (or zero) themes.\n- **Call `report_blocker` because no finding seems worth surfacing.** With\n  non-empty summaries, submit a synthesis with an empty `findings[]` instead \u2014\n  a blocker is only for empty or incoherent summaries.\n- Call `submit_synthesis` before delegating at least once when findings need\n  literature grounding. (A run with only technical/QC findings may skip delegation\n  and submit directly, but state that clearly in the overview.)\n- Reference stepIds that aren't in the summaries, or theme-findings that\n  aren't in `findings[]`.\n- Keep calling `submit_synthesis` after `accepted: true`. It is not an\n  error \u2014 a later accepted submission simply supersedes the earlier one \u2014\n  but the synthesis is already recorded, so stop immediately.\n- Use `submit_synthesis` as a validation probe. Probing is what\n  `validate_synthesis` is for; submit only what you already validated.\n- Submit a placeholder or stub payload to \"see what happens\". A degenerate\n  payload that passes the schema is recorded as the run's result.\n- End the session without a terminal tool call. That is a failure mode.\n";

package/dist/prompts/synthesis-agent.js

@@ -44,8 +44,8 @@ not like a scribe summarizing the Results section.
 
 ### literature_reviewer (research sub-agent — delegate focused research)
 A task-oriented sub-agent with access to bio-lookup tools (search_gene,
-search_pathway, lookup_go_term, search_interactions, pubmed,
-search_bgee_expression, get_impc_ko_profile). Delegate to it when you need
+lookup_annotation, search_interactions, pubmed,
+gene_preclinical_profile). Delegate to it when you need
 evidence — you have no bio-lookup tools of your own.
 
 Delegations must be **focused**:
@@ -119,11 +119,11 @@ clinical evidence, and be honest about the translational distance: is this
 interesting biology, or a validated target with a measurable biomarker and
 a known drug?
 
-**Assigning \`preclinical-validation\`** — cite IMPC mouse-KO phenotypes
-(\`get_impc_ko_profile\`) for loss-of-function consequences and
-cross-species baseline expression (\`search_bgee_expression\`) for
-tissue-of-action context, when the literature reviewer's report includes
-them.
+**Assigning \`preclinical-validation\`** — cite IMPC mouse-KO phenotypes for
+loss-of-function consequences and cross-species baseline expression for
+tissue-of-action context (both come back from
+\`gene_preclinical_profile\`), when the literature reviewer's report
+includes them.
 
 **What a good \`limitation\` looks like** — it names what it affects and
 why it matters:

package/dist/providers/errors.d.ts

@@ -77,6 +77,13 @@ export interface ProviderErrorClassification {
      */
     readonly retryable: boolean;
 }
+/**
+ * Walk the `cause` chain for the first numeric HTTP status. The single status
+ * walker: `classifyProviderError` keys on what this returns, so a caller asking
+ * "did the provider layer have a status to classify on?" must ask it here rather
+ * than re-implement the traversal.
+ */
+export declare function extractStatus(err: unknown): number | undefined;
 /**
  * Classify a provider failure by origin.
  *

package/dist/providers/errors.js

@@ -15,6 +15,7 @@
  * re-authenticating fixes it — which is a different remedy from every other
  * non-retryable 4xx, so it is a different kind.
  */
+import { redactSecrets } from "../input-sanitization.js";
 /**
  * Structural guard for an already-constructed `ProviderError` value. A
  * `ProviderError` is a plain object, not an `Error`, so it cannot be
@@ -71,7 +72,67 @@ export function toProviderError(e, workload) {
             cause: e,
         };
     }
-    return { type: "provider", retryable, message: detail, cause: e };
+    // The `provider` arm composes like its three siblings rather than forwarding
+    // the SDK message verbatim. It has to: when a 4xx body does not parse against
+    // the configured provider's error schema, the AI SDK falls back to
+    // `response.statusText`, so the "detail" is a bare HTTP reason phrase —
+    // `"Bad Request"` — that names neither the call nor the cause, while the
+    // status, the workload, and the body the SDK captured are all still on the
+    // `cause` chain right here.
+    //
+    // Composed strictly AFTER `classifyProviderError` has returned, so message
+    // text can never become a classification input: the harness-providers spec
+    // fixes classification on the HTTP status alone.
+    const status = extractStatus(e);
+    const lead = status === undefined ? `Provider call failed for ${workload}` : `Provider call failed for ${workload} (HTTP ${status})`;
+    // A transport that carries no reason phrase (an HTTP/2 hop yields
+    // `statusText === ""`) leaves `detail` empty; appending it regardless would
+    // trail a bare `": "` on an otherwise complete message.
+    const reason = detail.trim();
+    const diagnosed = reason ? `${lead}: ${reason}` : lead;
+    const body = extractResponseBody(e);
+    return {
+        type: "provider",
+        retryable,
+        // The excerpt trails deliberately — workload and status lead, so a
+        // downstream truncation (`profileFailureReason` cuts the line at 200)
+        // eats the least diagnostic content first.
+        message: body ? `${diagnosed} — response body: ${excerptResponseBody(body)}` : diagnosed,
+        cause: e,
+    };
+}
+/**
+ * Max characters of a captured provider response body carried in a message.
+ *
+ * Derived, not picked: the tightest downstream consumer (`profileFailureReason`,
+ * `tasks/data-profile.ts`) truncates the whole line at 200, and the lead this
+ * excerpt trails — a workload label plus `HTTP <status>` plus a reason phrase —
+ * runs to roughly 80. 120 is therefore the largest round value that cannot evict
+ * that lead.
+ *
+ * Deliberately NOT shared with that consumer's `PROFILE_ERROR_MAX_LEN`: that one
+ * bounds a `varchar` ledger column, this one bounds a message many non-ledger
+ * consumers read, and coupling them would make either one unmovable.
+ */
+const PROVIDER_BODY_EXCERPT_MAX_LEN = 120;
+/**
+ * Single-lined, secret-redacted, length-capped rendering of a captured response body. Bounding happens
+ * here rather than at a consumer because most `ProviderError` consumers truncate nothing at all, and the
+ * one that does would let an unbounded body crowd out the workload and status ahead of it.
+ *
+ * The body is an UNTRUSTED upstream/proxy payload, and this excerpt lands verbatim in the ledger's
+ * `data_profile_error` (surfaced to the UI) and the logs, whereas the composed lead does not — so
+ * secrets are redacted here and nowhere else on the message. Redaction runs on the FULL body before
+ * truncation: a token straddling the cut would otherwise be sliced into an unmatchable fragment that
+ * leaks. `redactSecrets` matches only prefixed formats (API keys, JWTs, bearer tokens, connection
+ * strings) and is safe on biological data, so a legitimate error body passes through intact.
+ */
+function excerptResponseBody(body) {
+    const singleLine = redactSecrets(body).replace(/\s+/g, " ").trim();
+    // Slice by CODE POINT, not UTF-16 unit: a raw byte body can carry astral characters, and a plain
+    // `.slice` could bisect a surrogate pair into a lone half that renders as U+FFFD.
+    const chars = [...singleLine];
+    return chars.length > PROVIDER_BODY_EXCERPT_MAX_LEN ? chars.slice(0, PROVIDER_BODY_EXCERPT_MAX_LEN - 1).join("") + "…" : singleLine;
 }
 /** Max links walked on the `cause` chain looking for a structured status. */
 const MAX_CAUSE_HOPS = 5;
@@ -88,8 +149,13 @@ const CONNECTION_ERROR_CODES = new Set([
     "UND_ERR_SOCKET",
 ]);
 const CONNECTION_ERROR_PATTERN = /fetch failed|socket hang up|network error|connection (?:refused|reset|error|closed)|econnrefused|enotfound|etimedout|terminated/i;
-/** Walk the `cause` chain for the first numeric HTTP status. */
-function extractStatus(err) {
+/**
+ * Walk the `cause` chain for the first numeric HTTP status. The single status
+ * walker: `classifyProviderError` keys on what this returns, so a caller asking
+ * "did the provider layer have a status to classify on?" must ask it here rather
+ * than re-implement the traversal.
+ */
+export function extractStatus(err) {
     let cursor = err;
     for (let i = 0; i < MAX_CAUSE_HOPS && cursor; i++) {
         const e = cursor;
@@ -101,6 +167,25 @@ function extractStatus(err) {
     }
     return undefined;
 }
+/**
+ * Walk the `cause` chain for the first captured provider response body.
+ *
+ * This is what recovers a proxy-minted or otherwise non-conforming error body:
+ * the AI SDK keeps the raw bytes on `APICallError.responseBody` even when its
+ * own parse against the provider's error schema fails and its `message` degrades
+ * to the HTTP reason phrase. A blank body is treated as absent — an empty
+ * `— response body:` segment says less than no segment at all.
+ */
+function extractResponseBody(err) {
+    let cursor = err;
+    for (let i = 0; i < MAX_CAUSE_HOPS && cursor; i++) {
+        const e = cursor;
+        if (typeof e.responseBody === "string" && e.responseBody.trim() !== "")
+            return e.responseBody;
+        cursor = e.cause;
+    }
+    return undefined;
+}
 /** Does any link of the `cause` chain look like a transport-level failure? */
 function looksLikeConnectionError(err) {
     let cursor = err;

package/dist/runtime/pools.d.ts

@@ -1,5 +1,6 @@
 /**
- * Per-pod Postgres pool sizing — the single source of truth.
+ * Per-pod Postgres pool sizing and acquisition bounds — the single source of
+ * truth.
  *
  * Cortex runs two pools per pod against the same cluster (see the postgres-storage-backend spec): the
  * application pool (`lib/storage.ts::createPool()`) and the DBOS system-DB
@@ -21,5 +22,18 @@ export declare const DEFAULT_APP_POOL_SIZE = 12;
  * overlap during DBOS recovery, replication / monitoring users.
  */
 export declare const SAFETY_MARGIN = 5;
+/**
+ * How long a caller may wait for a connection from the app pool before the
+ * acquisition fails.
+ *
+ * The driver waits forever by default, which leaves a caller on a saturated
+ * pool with no failure mode at all — only an indefinite hang, indistinguishable
+ * from work still in progress and therefore able to stall the caller's own
+ * in-flight guard permanently. A bound turns that silent stall into a surfaced
+ * error the caller can degrade on. 30s is long enough that a healthy pool under
+ * burst never trips it, and short enough that a wedged caller surfaces well
+ * inside a human's patience.
+ */
+export declare const APP_POOL_ACQUIRE_TIMEOUT_MS = 30000;
 /** Resolve the app pool size from the optional `DB_POOL_MAX` override. */
 export declare function resolveAppPoolSize(dbPoolMax: string | undefined): number;

package/dist/runtime/pools.js

@@ -1,5 +1,6 @@
 /**
- * Per-pod Postgres pool sizing — the single source of truth.
+ * Per-pod Postgres pool sizing and acquisition bounds — the single source of
+ * truth.
  *
  * Cortex runs two pools per pod against the same cluster (see the postgres-storage-backend spec): the
  * application pool (`lib/storage.ts::createPool()`) and the DBOS system-DB
@@ -21,6 +22,19 @@ export const DEFAULT_APP_POOL_SIZE = 12;
  * overlap during DBOS recovery, replication / monitoring users.
  */
 export const SAFETY_MARGIN = 5;
+/**
+ * How long a caller may wait for a connection from the app pool before the
+ * acquisition fails.
+ *
+ * The driver waits forever by default, which leaves a caller on a saturated
+ * pool with no failure mode at all — only an indefinite hang, indistinguishable
+ * from work still in progress and therefore able to stall the caller's own
+ * in-flight guard permanently. A bound turns that silent stall into a surfaced
+ * error the caller can degrade on. 30s is long enough that a healthy pool under
+ * burst never trips it, and short enough that a wedged caller surfaces well
+ * inside a human's patience.
+ */
+export const APP_POOL_ACQUIRE_TIMEOUT_MS = 30_000;
 /** Resolve the app pool size from the optional `DB_POOL_MAX` override. */
 export function resolveAppPoolSize(dbPoolMax) {
     if (dbPoolMax === undefined || dbPoolMax === "")

package/dist/sandbox/sandbox-step-translate.d.ts

@@ -1,10 +1,23 @@
 /**
  * Pure translation between the agent-loop / sandbox event stream and the
  * typed per-step parts the frontend renders. No DBOS, no per-run state — just the
- * label mapping, the file-tree delta extraction/fold, and the chat-data-part
- * narrowing the `sandbox-step` workflow body composes into its emitters.
+ * reconciliation-id construction, the label mapping, the file-tree delta
+ * extraction/fold, and the chat-data-part narrowing a workflow body composes
+ * into its emitters.
  */
 import type { ChatDataPart, EmitFn } from "../loop/types.js";
+/**
+ * Stable reconciliation id for a step's reconciling parts
+ * (`data-step-activity`, `data-step-file-tree`). One id per (runId, stepId)
+ * so the run-stream fold collapses every phase transition latest-wins onto
+ * a single frame. The client keys these by `stepId`, but the server fold
+ * keys by part `id`, so the id MUST be unique per step within the run.
+ *
+ * Every producer of these parts mints its ids here: the id is a
+ * reconciliation contract, and the fold collapses correctly only while all
+ * producers construct it identically.
+ */
+export declare function stepPartId(kind: string, runId: string, stepId: string): string;
 export declare function activityForTool(name: string, input?: unknown): string;
 /** On-change working-tree delta the sandbox executor posts per exec (paths
  *  only; the executor skips directories). */

package/dist/sandbox/sandbox-step-translate.js

@@ -1,9 +1,24 @@
 /**
  * Pure translation between the agent-loop / sandbox event stream and the
  * typed per-step parts the frontend renders. No DBOS, no per-run state — just the
- * label mapping, the file-tree delta extraction/fold, and the chat-data-part
- * narrowing the `sandbox-step` workflow body composes into its emitters.
+ * reconciliation-id construction, the label mapping, the file-tree delta
+ * extraction/fold, and the chat-data-part narrowing a workflow body composes
+ * into its emitters.
  */
+/**
+ * Stable reconciliation id for a step's reconciling parts
+ * (`data-step-activity`, `data-step-file-tree`). One id per (runId, stepId)
+ * so the run-stream fold collapses every phase transition latest-wins onto
+ * a single frame. The client keys these by `stepId`, but the server fold
+ * keys by part `id`, so the id MUST be unique per step within the run.
+ *
+ * Every producer of these parts mints its ids here: the id is a
+ * reconciliation contract, and the fold collapses correctly only while all
+ * producers construct it identically.
+ */
+export function stepPartId(kind, runId, stepId) {
+    return `${kind}-${runId}-${stepId}`;
+}
 /** Friendly live-activity label per sandbox tool id. Falls back to the raw
  *  tool name so a newly added tool still reads sensibly. */
 const TOOL_ACTIVITY = {

package/dist/schemas/workflow-state.d.ts

@@ -7,8 +7,8 @@
 import { z } from "zod";
 /**
  * A step of an analysis plan. `PlanStepSchema` (schemas/plan-schemas.ts) narrows
- * this into the planner's output contract and emits it as the `validate_plan` /
- * `submit_plan` arg schema — so each field's meaning belongs in `.describe()`,
+ * this into the planner's output contract and emits it as the `submit_plan`
+ * arg schema — so each field's meaning belongs in `.describe()`,
  * not in a comment the model never sees.
  */
 export declare const AnalysisStepSchema: z.ZodObject<{

package/dist/schemas/workflow-state.js

@@ -8,8 +8,8 @@ import { z } from "zod";
 // ── Plan structures ─────────────────────────────────────────────────
 /**
  * A step of an analysis plan. `PlanStepSchema` (schemas/plan-schemas.ts) narrows
- * this into the planner's output contract and emits it as the `validate_plan` /
- * `submit_plan` arg schema — so each field's meaning belongs in `.describe()`,
+ * this into the planner's output contract and emits it as the `submit_plan`
+ * arg schema — so each field's meaning belongs in `.describe()`,
  * not in a comment the model never sees.
  */
 export const AnalysisStepSchema = z.object({

package/dist/state/data-profile.d.ts

@@ -101,6 +101,13 @@ export interface DataProfileStatus {
     startedAt: string | null;
     completedAt: string | null;
     result: DataProfileResult | null;
+    /**
+     * The DBOS workflow id of the profile attempt that owns this row — the durable
+     * event stream a consumer subscribes to for this profile's activity. `null` means
+     * this profile's stream is not addressable (see
+     * {@link recordDataProfileWorkflowId}).
+     */
+    workflowId: string | null;
     seedInputFileIds: string[] | null;
 }
 /**
@@ -117,14 +124,59 @@ export interface DataProfileStatus {
  * unseeded — neither is an error, both stay in the ok channel.
  */
 export declare function tryStartDataProfile(pool: Querier, analysisId: string): ResultAsync<boolean, DbError>;
-/** Claim a `failed` row back into `running` (the deliberate-retry route). Carries {@link SEEDED}. */
+/**
+ * Claim a `failed` row back into `running` (the deliberate-retry route). Carries {@link SEEDED}.
+ *
+ * Clears `data_profile_workflow_id`, because the claim IS the moment a new attempt takes the row
+ * and the prior attempt's workflow is finished. Left in place it would leave the row `running`
+ * while naming a stream that has already drained, so a consumer would subscribe and observe
+ * nothing without knowing why; NULL says "not addressable yet", which is exactly true until the
+ * new body records its own id (see {@link recordDataProfileWorkflowId}).
+ */
 export declare function tryRetryDataProfile(pool: Querier, analysisId: string): ResultAsync<boolean, DbError>;
 /**
  * Claim a `completed` row back into `running` (the re-profile route). `data_profile_result`
  * is deliberately preserved so a consumer can keep serving the prior profile while the new
  * one runs. Carries {@link SEEDED}.
+ *
+ * `data_profile_workflow_id` is NOT preserved alongside it, and the asymmetry is the point: the
+ * result is CONTENT that stays valid until replaced, while the id is a POINTER to a live stream
+ * whose workflow is now finished. Keeping it would leave the row `running` while naming a drained
+ * stream — see {@link tryRetryDataProfile} for the same reasoning.
  */
 export declare function tryRerunDataProfile(pool: Querier, analysisId: string): ResultAsync<boolean, DbError>;
+/**
+ * Record the DBOS workflow id of the attempt that owns a claimed-`running` row, so a
+ * consumer resolves which durable event stream carries this profile's activity from the
+ * ledger row alone — no durability-engine query, no id reconstructed from the workflow-id
+ * string format. The workflow BODY calls this, never the trigger: the claim CAS runs
+ * before the workflow id is minted, so only the body can report the id of the attempt
+ * that actually started.
+ *
+ * `AND data_profile_status = 'running'` buys exactly one thing: a write that lands late
+ * cannot stamp a row that has already settled, which would otherwise point a consumer at
+ * a workflow for a profile that is already finished. What it does NOT buy is
+ * disambiguation between two attempts that each believe they are the running one — the
+ * stale-expiry claim admits precisely that, since a row whose `data_profile_started_at`
+ * has aged past the timeout can be claimed by a second attempt while the first body is
+ * still alive but has not completed its first step, and that first step then overwrites
+ * the second's id.
+ *
+ * That residue is deliberately left open rather than closed. Its worst outcome is already
+ * a specified-normal state: a consumer subscribed to a superseded workflow reads a stream
+ * that has already drained, so it observes no activity — indistinguishable from "running,
+ * nothing reported yet". A missing activity line for one profile is acceptable; a wrong
+ * one would not be. And closing it costs more than it buys: either the three claim
+ * functions widen their `Result<boolean>` returns to carry the id — their callers branch
+ * on truthiness (`if (!retried)`), so an object return makes every such branch
+ * always-taken, a silent behaviour change in the embedder's recovery path — or the
+ * embedder mints the workflow ids, putting a harness-internal construction in a
+ * consumer's hands.
+ *
+ * `ok(true)` when this call stamped the row; `ok(false)` when the CAS refused it — a
+ * normal in-band outcome, not an error.
+ */
+export declare function recordDataProfileWorkflowId(pool: Querier, analysisId: string, workflowId: string): ResultAsync<boolean, DbError>;
 /**
  * Stamp a claimed-`running` row `completed` and record its result — a terminal
  * write CAS'd on `data_profile_status = 'running'`.

package/dist/state/data-profile.js

@@ -38,21 +38,31 @@ export function tryStartDataProfile(pool, analysisId) {
     return tryMutation("dataProfile.tryStartDataProfile", async () => {
         const result = await pool.query({
             text: `UPDATE cortex_analysis_state
-            SET data_profile_status = 'running', data_profile_started_at = $1
+            SET data_profile_status = 'running', data_profile_started_at = $1,
+                data_profile_workflow_id = NULL
             WHERE analysis_id = $2 AND (data_profile_status = 'pending' OR data_profile_status IS NULL) AND ${SEEDED}`,
             values: [now, analysisId],
         });
         return (result.rowCount ?? 0) > 0;
     });
 }
-/** Claim a `failed` row back into `running` (the deliberate-retry route). Carries {@link SEEDED}. */
+/**
+ * Claim a `failed` row back into `running` (the deliberate-retry route). Carries {@link SEEDED}.
+ *
+ * Clears `data_profile_workflow_id`, because the claim IS the moment a new attempt takes the row
+ * and the prior attempt's workflow is finished. Left in place it would leave the row `running`
+ * while naming a stream that has already drained, so a consumer would subscribe and observe
+ * nothing without knowing why; NULL says "not addressable yet", which is exactly true until the
+ * new body records its own id (see {@link recordDataProfileWorkflowId}).
+ */
 export function tryRetryDataProfile(pool, analysisId) {
     const now = new Date().toISOString();
     return tryMutation("dataProfile.tryRetryDataProfile", async () => {
         const result = await pool.query({
             text: `UPDATE cortex_analysis_state
             SET data_profile_status = 'running', data_profile_started_at = $1,
-                data_profile_error = NULL, data_profile_completed_at = NULL
+                data_profile_error = NULL, data_profile_completed_at = NULL,
+                data_profile_workflow_id = NULL
             WHERE analysis_id = $2 AND data_profile_status = 'failed' AND ${SEEDED}`,
             values: [now, analysisId],
         });
@@ -63,6 +73,11 @@ export function tryRetryDataProfile(pool, analysisId) {
  * Claim a `completed` row back into `running` (the re-profile route). `data_profile_result`
  * is deliberately preserved so a consumer can keep serving the prior profile while the new
  * one runs. Carries {@link SEEDED}.
+ *
+ * `data_profile_workflow_id` is NOT preserved alongside it, and the asymmetry is the point: the
+ * result is CONTENT that stays valid until replaced, while the id is a POINTER to a live stream
+ * whose workflow is now finished. Keeping it would leave the row `running` while naming a drained
+ * stream — see {@link tryRetryDataProfile} for the same reasoning.
  */
 export function tryRerunDataProfile(pool, analysisId) {
     const now = new Date().toISOString();
@@ -70,13 +85,56 @@ export function tryRerunDataProfile(pool, analysisId) {
         const result = await pool.query({
             text: `UPDATE cortex_analysis_state
             SET data_profile_status = 'running', data_profile_started_at = $1,
-                data_profile_error = NULL, data_profile_completed_at = NULL
+                data_profile_error = NULL, data_profile_completed_at = NULL,
+                data_profile_workflow_id = NULL
             WHERE analysis_id = $2 AND data_profile_status = 'completed' AND ${SEEDED}`,
             values: [now, analysisId],
         });
         return (result.rowCount ?? 0) > 0;
     });
 }
+/**
+ * Record the DBOS workflow id of the attempt that owns a claimed-`running` row, so a
+ * consumer resolves which durable event stream carries this profile's activity from the
+ * ledger row alone — no durability-engine query, no id reconstructed from the workflow-id
+ * string format. The workflow BODY calls this, never the trigger: the claim CAS runs
+ * before the workflow id is minted, so only the body can report the id of the attempt
+ * that actually started.
+ *
+ * `AND data_profile_status = 'running'` buys exactly one thing: a write that lands late
+ * cannot stamp a row that has already settled, which would otherwise point a consumer at
+ * a workflow for a profile that is already finished. What it does NOT buy is
+ * disambiguation between two attempts that each believe they are the running one — the
+ * stale-expiry claim admits precisely that, since a row whose `data_profile_started_at`
+ * has aged past the timeout can be claimed by a second attempt while the first body is
+ * still alive but has not completed its first step, and that first step then overwrites
+ * the second's id.
+ *
+ * That residue is deliberately left open rather than closed. Its worst outcome is already
+ * a specified-normal state: a consumer subscribed to a superseded workflow reads a stream
+ * that has already drained, so it observes no activity — indistinguishable from "running,
+ * nothing reported yet". A missing activity line for one profile is acceptable; a wrong
+ * one would not be. And closing it costs more than it buys: either the three claim
+ * functions widen their `Result<boolean>` returns to carry the id — their callers branch
+ * on truthiness (`if (!retried)`), so an object return makes every such branch
+ * always-taken, a silent behaviour change in the embedder's recovery path — or the
+ * embedder mints the workflow ids, putting a harness-internal construction in a
+ * consumer's hands.
+ *
+ * `ok(true)` when this call stamped the row; `ok(false)` when the CAS refused it — a
+ * normal in-band outcome, not an error.
+ */
+export function recordDataProfileWorkflowId(pool, analysisId, workflowId) {
+    return tryMutation("dataProfile.recordDataProfileWorkflowId", async () => {
+        const result = await pool.query({
+            text: `UPDATE cortex_analysis_state
+            SET data_profile_workflow_id = $1
+            WHERE analysis_id = $2 AND data_profile_status = 'running'`,
+            values: [workflowId, analysisId],
+        });
+        return (result.rowCount ?? 0) > 0;
+    });
+}
 /**
  * Stamp a claimed-`running` row `completed` and record its result — a terminal
  * write CAS'd on `data_profile_status = 'running'`.
@@ -213,7 +271,8 @@ export function clearDataProfile(pool, analysisId) {
             text: `UPDATE cortex_analysis_state
             SET data_profile_status = NULL, data_profile_error = NULL,
                 data_profile_started_at = NULL, data_profile_completed_at = NULL,
-                data_profile_result = NULL, seed_input_file_ids = NULL
+                data_profile_result = NULL, data_profile_workflow_id = NULL,
+                seed_input_file_ids = NULL
             WHERE analysis_id = $1 AND data_profile_status IS DISTINCT FROM 'running'`,
             values: [analysisId],
         });
@@ -242,7 +301,7 @@ export function loadDataProfileStatus(pool, analysisId) {
         const result = await pool.query({
             text: `SELECT data_profile_status, data_profile_error,
                    data_profile_started_at, data_profile_completed_at,
-                   data_profile_result, seed_input_file_ids
+                   data_profile_result, data_profile_workflow_id, seed_input_file_ids
             FROM cortex_analysis_state WHERE analysis_id = $1`,
             values: [analysisId],
         });
@@ -255,6 +314,7 @@ export function loadDataProfileStatus(pool, analysisId) {
             startedAt: row.data_profile_started_at ?? null,
             completedAt: row.data_profile_completed_at ?? null,
             result: row.data_profile_result ?? null,
+            workflowId: row.data_profile_workflow_id ?? null,
             seedInputFileIds: row.seed_input_file_ids ?? null,
         };
     });

package/dist/state/index.d.ts

@@ -12,15 +12,15 @@ export { upsertAnalysis, resolveAnalysisBilling, suspendAnalysis, resumeAnalysis
 export { upsertArtifact, upsertArtifacts, queryInputArtifacts, queryStepArtifactPaths, queryUnsyncedStepArtifacts, updateArtifactId, updateFileIds, countArtifactsForRun, } from "./artifacts.js";
 export type { RegisterArtifactInput, InputArtifactMeta, StepArtifactRef } 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";
-export type { InsertRunInput, RunReservation } from "./runs.js";
+setRunSynthesisOutcome, queryRun, queryActiveRun, queryNonTerminalRunsByAnalysis, queryRunsForInspection, queryRunsByAnalysis, queryRunsByThread, } from "./runs.js";
+export type { InsertRunInput, RunPage, RunReservation } from "./runs.js";
 export { insertStepExecution, seedStepExecutions, sweepPendingStepExecutions, updateStepExecution, queryStepsByRun } from "./step-executions.js";
 export type { InsertStepExecutionInput, SeedStepExecutionRow, UpdateStepExecutionInput } from "./step-executions.js";
 export { setSandboxRef, setActiveExecId, clearSandboxRef, queryActiveSandboxes, reconcileReapedSandbox } from "./active-sandboxes.js";
 export type { ActiveSandboxRow } from "./active-sandboxes.js";
 export { insertPlan, upsertPlan, loadPlan } from "./plans.js";
 export type { InsertPlanInput, UpsertPlanInput } 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 type { DataProfileStatus, DataProfileResult, DataProfileInputFile, DataProfileFile, DataProfileQualityAssessment } 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";