R8 · depictio and LabID drift¶

Done 2026-10-26 · 15 findings: 1 blocker, 6 majors, 8 minors · 0 dropped · 6 questions for Thomas · 4 spikes proposed

What changed¶

New review file: docs/reviews/R8-depictio.md. It holds:
- the 15 findings DL-101 to DL-115, ranked by severity, each with its evidence (depictio or LabID file:line), a proposal and Status: open;
- a findings table with the specs each finding touches and the reviewer's draft ID;
- an overlap table: four findings extend an earlier open finding (R2 FC-003, R5 SEC-120, R1 SR-023, R5 SEC-121) and say only what is new;
- 6 questions for Thomas;
- 4 proposed spikes (depictio-handoff, depictio-embed, depictio-recipe-runner, depictio-introspection);
- Appendix A: a draft of the dated research note the prompt asked for, docs/research/depictio-audit-2026-10-26.md. It is not a file yet; /apply-findings R8-depictio writes it if DL-111 is accepted;
- Appendix B: the status of the requests to depictio on 2026-10-26 (1 done, 3 partly done, 7 new, and 1 to restore (QC-4)), proposed to replace ecosystem §3.
No spec was edited. This is a review round (see the review rules in docs/reviews/README.md). The spec changes and the research note wait for TRIAGE1 and APPLY1.
The file was committed on autopilot/integration in ad6bc9b, together with the other W1 review files, the nav entry and map.md.

Why¶

Spectio reuses depictio (identity, storage, the QC catalogue, dashboards) and plans a LabID plugin. The specs describe that reuse from audits dated 2026-10-25. Before any code, every claim about depictio and LabID must be checked against their current code, and the list of requests to depictio must show what is done.

Prompt: next-phase.md · R8. It asks depictio-liaison to re-check every claim in api §13, depictio-ecosystem-reuse.md and the research notes, to propose a new dated research note, and to update the status of the requests to depictio. The round runs as an autopilot step: decision log, 2026-10-26, autopilot. The decisions most findings test are one QC for Spectio and depictio (api §13.6) and the MVP scope, which puts the automatic depictio hand-off after 0.1 (decision log, 2026-10-26, MVP scope).

Evidence¶

How the round ran (from the round's header in the review file):

Item	Value
Reviewers	`depictio-liaison`, one instance. It returned a full report; none failed.
Scope	api §13, `depictio-ecosystem-reuse.md`, and the `docs/research/depictio-*.md` notes
depictio	shallow read-only clone of `main` at `0d1aa0a` (2026-10-23), version 1.19.2. `git ls-remote` on 2026-10-26 still gives `0d1aa0a`, so depictio has not changed since the dated audits: every finding is about a claim that was wrong or incomplete when written.
LabID	`labid-server` `52d3952` (read for the first time), `labid-lib` `cd14636`, `labid-cli` `5af9e16`, from `gitlab.com/lab-integrated-data`
Merge	IDs renumbered in rank order; the reviewer's draft IDs kept in the table's last column. 0 duplicates merged (one reviewer). R8b (`DEP-T-`) and R12 (`UX-`) findings are cited, not repeated.
Merger's check	every blocker and major was re-checked against the depictio clone at `0d1aa0a`. All reproduced, so 0 findings were dropped. Minors were spot-checked, not re-read line by line.
Corrections during the merge	DL-103: `location /dashboard/` re-declares `add_header`, so the server-level framing headers probably do not reach it [to be validated: inference, not executed]. DL-104: recount gives 186 of 339 recipe modules with `dc_ref` (the reviewer had 185 of 338). DL-101: citation completed with `core_functions.py:872-911`. The conclusions did not change.

Counts, checked against the file's headings and findings table:

$ for s in blocker major minor; do printf "%s " $s; grep -c "^### DL-[0-9]* · $s ·" docs/reviews/R8-depictio.md; done
blocker 1
major 6
minor 8
$ grep -cE '^\| DL-[0-9]+ \| (blocker|major|minor) \|' docs/reviews/R8-depictio.md
15

These match the summary table in the file (1 blocker, 6 majors, 8 minors, total 15, dropped 0) and the merge summary returned by the step's workers (1 blocker, 6 majors, 8 minors, 0 dropped).

Exit criterion. R8 is done when its review file exists, so that TRIAGE1 can read it:

$ ls docs/reviews/R8-depictio.md
docs/reviews/R8-depictio.md

Figures and media¶

None required (review step).

Findings and open questions¶

The five findings that matter most (as ranked in the review file's summary):

DL-101 · blocker: the runner-side depictio-cli ingest of api §13.3 needs depictio's instance provisioning key, which can mint 1-year shared tokens for any email, admins included, and depictio's S3 write secret. §13.1 forbids both on runners, and on Compose the S3 endpoint has no host port. Extends R2 FC-003, whose fix removes the key but not the S3 secret.
DL-102 · major: depictio JWTs carry no iss, aud, email or jti, revocation is a database lookup, and the browser session lives in depictio-origin localStorage. v1 trust must go through GET /auth/me, and before SSO "one login for both" exists only in the CLI. Extends R5 SEC-120.
DL-103 · major: the gate-time Dashboard tab cannot embed depictio from another origin: the frame is refused, or it loads without a session [to be validated]. A depictio-embed filter and ready message protocol already exists, so request 9 needs rewording.
DL-104 · major: 61 MultiQC-section catalogue outputs have no columns, and 186 of 339 recipe modules use dc_ref, which the standalone runner skips with exit 0 and no table. This affects 0.1, whose focus is checks. Related to R1 SR-023.
DL-105 · major: run_tag = Spectio run ID cannot be set, because a flat run is named after its directory. --attach-run recipe collections read only the first run, and --result-json returns no run ID. The proposal is to ingest through a <run-id> symlink and use one depictio project per Spectio run.

Questions for Thomas. The full wording is in the review file. In short:

#	Topic	Question
1	Where ingestion runs (DL-101, R2 FC-003)	On the runner with a bucket-scoped SeaweedFS identity, on an ingest relay next to depictio, or wait for depictio's request 13? Should DL-101 supersede FC-003's proposal, and stay a blocker although the hand-off is post-0.1?
2	depictio projects (DL-105)	One depictio project per Spectio run, or one per Spectio project with `attach_run`? With `attach_run`, recipe tables show the first run until depictio fixes it.
3	One login for both (DL-102, R5 SEC-120)	Accept that before SSO the single login exists only in the CLI (`--with-depictio`), and that the browser needs a shared identity provider?
4	Dashboard tab (DL-103, R5 SEC-109, DEP-T-013)	Show the tab only when Spectio and depictio share one origin, with a deep link plus a preset filter state otherwise?
5	Reporting to depictio (DL-113, DL-103)	`/auth/me` returns the password hash [inference, not executed], and `/dashboard/` probably has no framing headers. Report both privately to depictio now? File the 18 requests as one tracking issue or one issue each?
6	Catalogue bindings in 0.1 (DL-104, R1 SR-023)	Bind 0.1 checks only to Spectio's own bindings and `multiqc.parquet`, with catalogue bindings waiting for a public `depictio recipe run` that resolves `dc_ref`?

Next. TRIAGE1 sorts these findings with the triage policy, together with the related R1, R2, R5 and R8b findings. It moves the questions it cannot settle to the inbox. APPLY1 then changes the specs, writes the research note from Appendix A, replaces ecosystem §3 with Appendix B if DL-111 is accepted, and adds the decision-log entries.