open.csr — the Clinical Study Report builder (web app)

Goal issue #112 · slug csr

1/6 member issues closed

🟢 Ready for auto 1

obot can implement these unattended (label auto).

#130 open.csr display change-request loop — the writer proposes, the agent drafts, the statistician signs the diff (Backlog)

Other open members 4

no readiness label yet.

#111 open.csr — open-source Clinical Study Report builder (Development · ai)
#113 open.csr Demo surface — one app, four tabs, and the move from reader to editor (Development · ai)
#129 open.csr submission outputs — RTF tables/listings, a values store, and seamless Reader editing (Review · ai)
#179 open.csr Reader editing — closing the seam between reading and writing (Backlog · ai)

✅ Done 1

closed members.

#115 text review and sign-off in the app — the first editing verb (Released · ai)

Direction

Standing goal — this issue stays open; closing it = retiring the goal. Direction and membership are maintained by @jwildfire; autonomous sessions propose changes as comments and never edit this issue or its sub-issue links.

Intent

Build open.csr, an open-source Clinical Study Report builder that closes the loop between the numbers and the words: a change request becomes a code edit, which regenerates the number, which updates the sentence — as one versioned transaction, with every iteration saved and reproducible.

Research at kickoff (2026-07-25) established that no open-source CSR builder exists, and that every tool in the field breaks the same seam — prose quotes numbers the authoring tool did not compute. Commercial vendors sell patches for that seam. Closing it is the whole point of this goal.

The deliverable is a web app, not an R package

This is the constraint that shapes every increment: open.csr is a web application. Users experience it in the browser — that is where TFLs are viewed, text is edited, templates are assembled, and change requests are made.

An R engine is fine and expected — the ARD/TFL pipeline belongs in R, on the pharmaverse ARD stack ({cards}/{gtsummary}/{tfrmt}/{r2rtf}). What is not the deliverable is an R package as the product surface.
Not Shiny. The app is not a Shiny front end over the engine.
WebAssembly R (webR) is a promising path and worth evaluating seriously: it would let the browser run the real pipeline with no server, keeping the app static and shareable while preserving genuine regeneration rather than a mock. The R Consortium's Pilot 4a found FDA reviewers preferred a WebAssembly delivery to containers, so the precedent is favorable. Today's demo is static and precomputed — the open question is what makes the editor live.

Boundaries and weights for a selecting session

Next increment is the Demo/editor transition (@jwildfire, 2026-07-25): fold the separate reader, gallery, and text views into one Demo surface — a homepage plus tabs for Reader / Tables / Text / Templates — and move from a reader to an editor as fast as possible. Editing is the point; browsing is table stakes.
Priority order after that: make the loop editable, then make it credible to a statistician (submission-format RTF, a figure, FDA Standard Safety Tables alignment), then close the agentic loop (change request → spec edit → regenerated ARD diff → PR).
Prerequisite: the obotclaw App is not yet installed on jwildfire/open.csr — until it is, agent commits push under @jwildfire's identity rather than the bot. Resolved 2026-07-29: the App install was verified present on jwildfire/open.csr and @jwildfire promoted the repo to the auto profile in the same decision (obot.agent ac613bf); agent commits push as obotclaw[bot]. Re-verified 2026-08-14: the App is installed on all 12 repos.
Demo data stays {pharmaverseadam} CDISCPILOT01 — public and regenerable. No proprietary study data in the repo, ever.
Four agent-drafted text blocks sit at approval.state: draft awaiting @jwildfire's review; they are excluded from the assembled report by the approval gate, which is correct behavior to demonstrate rather than a defect to fix.

Membership

Members are the issues linked as sub-issues — requirements or lightweight tasks (per the #53 policy, small items may live directly under a goal without a requirement wrapper). A newly linked sub-issue is automatically a member; nothing here is hand-maintained. Priority is the selecting session's judgment at session start, guided by the boundaries above (--increment overrides). The repo-level backlog feed is the jwildfire/open.csr issue backlog.

This issue was drafted by Claude Code using Fable 5 in an unattended ultracode session and not yet reviewed by @jwildfire

Members are generated from the goal issue's sub-issue links at build time; priority is the selecting session's judgment, not list order (#53 v2). The --auto policy binding — active/paused, grant profile, repo-level backlog feeds — lives in obot.agent/goals/registry.json. Readiness labels: auto = ready for autonomous implementation, draft = needs @jwildfire steering.