pdombkins makes the document library project-aware

This fork turns a shared document store into a clearer system for organising project material and tracing where it came from.

knowledge-managementworkflow

pdombkins has built out central document management so teams can keep material in one Library while linking it into the projects where it is needed. The work also improves visibility for people reviewing documents and agent activity.

Folders organise the central document Library and can be connected to projects.
Linked project documents retain their source folder, so users can see their provenance.
Virtual folders group linked documents without duplicating them.
Alphabetical sorting makes larger collections easier to scan.
The admin view now shows full project names and reliable document filenames.
Role-specific sources and a scrollable run history add context around agent work.

The result is less a document dump and more a navigable record of what belongs to each matter or project.

So what Legal teams managing reusable precedents alongside project-specific materials should care because this makes organisation and provenance easier to follow.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

6 commits from pdombkins/rose_lawyer, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`104422e5`	Central document management (Library→projects linking) + agent playbook/document transparency	Peter Dombkins	2026-07-24	↗ GitHub
`23c3d77b`	Fix: include current_version_id in admin document-library so filenames render	Peter Dombkins	2026-07-24	↗ GitHub
`b40a2ed0`	Full project names in Admin Documents matrix; specific per-role sources + scrollable run list on Agents	Peter Dombkins	2026-07-24	↗ GitHub
`492cbdb5`	Admin Documents: folders, linked to projects, documents inherit folder links	Peter Dombkins	2026-07-25	↗ GitHub
`ec4d2660`	feat(documents): surface the source Library folder on linked project docs	Peter Dombkins	2026-07-31	↗ GitHub
commit body A linked document is one row shared across every project it is linked into, and folder_id is a single column, so it cannot sit in each project's folder tree - which is why 31 documents arrive flat at the project root. loadLinkedDocumentsForProject now returns linked_folder_name and the Shared badge reads 'Shared · Week 9 - change management', so provenance is visible. The full virtual-folder grouping in DocTable is not done: that component is ~3,000 lines and renders every student's documents, so it wants its own pass.
`1f6a6264`	feat(documents): virtual folders for linked docs; alphabetical by default	Peter Dombkins	2026-07-31	↗ GitHub
commit body Linked documents are one row shared across every project they are linked into, and folder_id is a single column, so they cannot sit in each project's folder tree - 31 files landed flat at the root of every group project. DocTable now groups them under read-only virtual folders named after the source Library folder, using linked_folder_name from the backend. The document-row JSX was extracted verbatim from the childDocs.map() body into renderDocumentRow(doc, depth) so the same row can render inside a virtual folder. Behaviour unchanged; only the call site moved. Sorting: both the document sort and the folder sort were gated on enableHeaderFilters, which only LibraryWorkspace sets, so everything came back in insertion order. Ungated - folders and documents are ascending alphabetical by default in the Library and in projects.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-937.md from inside the repo you want the changes in.

⬇ Download capture-thread-937.md