You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@salmonumbrella — thank you for the work and the detailed proposals. We need to reset how this work is scoped and delivered.
We have closed all 260 of your PRs that were open in this repository at the start of this review. None was merged. The seven existing PRs from other contributors remain open. The volume, overlapping implementations, and dependencies make this queue impractical to review and maintain. We will move forward with a smaller, coherent scope that the maintainers can implement and review in manageable increments.
This is a decision about scope and delivery, not a claim that every proposal is wrong. The closed PRs remain available as references. Please pause additional PRs for these workstreams, and do not rebase or resubmit this stack while we agree on the replacement scope here.
Review overview
The inventory covers the 260 PRs open at the start of this review. All target main. The source baseline is 7bf6a59b, which matched main when checked.
Exact passages, section/context reading, remote targeting, scoped access, index repair, tag concepts, curated maps and refresh
Defer; exact historical citations can be a separate follow-up
Total
260
This is a highly overlapping queue, not 260 independent changes:
218 PRs change more than 100 files; 191 change more than 300. Complete file inventories contain 91,154 repeated file entries across 1,005 distinct paths. Those are overlap counts, not unique implementation size.
Expose production supplements in embedded vaults #718 shows 130,636 additions and 14,677 deletions across 623 files and 201 commits. Its title describes one small embedded API addition; its PR diff also carries a large inherited stack.
Complete inventories: 212 production proposals, 33 native-workflow proposals, and 15 discovery proposals. Every PR has a proposed increment, disposition, cumulative file count, and reviewed head. Review coverage: every PR description and complete changed-file inventory was catalogued; representative diffs, dependency relationships, and the current implementation were inspected. This is a scope and architecture review, not a line-by-line correctness audit or a claim that the proposed code passes tests.
Umbrella: finish the local document review-to-export workflow
Status: the cleanup in #721, sealed-snapshot load-file exports in #403, exact selected-document reports in #726, CLI native exports with explicit release in #740, local MCP native exports in #749, local MCP search reports in #753, and CLI report inspection/download recovery in #754 are merged. The next proposed slice is qualification of the existing report/export workflow with a small synthetic PDF corpus and physical backup/restore. Its scope and written specification remain to be reviewed; the complete acceptance assessment is still open.
The proposal inventory above records the original review. It is historical context, not a current merge checklist. The implemented report design supersedes this issue's original live-source-withdrawal rule: captured reports remain usable until their existing expiry, while a new run checks its selected sources again.
A local Docbank operator should be able to select a bounded set of documents, review the exact selected versions, produce a frozen keyword/date report with honest coverage, and download a verified archive of those same documents. The same bounded task should be usable from the web app, CLI, and local operator MCP.
Start with retained documents and already available renditions. A PDF without retained text can still be exported; the report must show the missing evidence rather than treating it as a zero-hit document. Creating a report or export must not start extraction, OCR, embeddings, or a hosted provider request.
Reuse the implementation already on main
The daemon already registers workspace, rendition, export, report, package-import and Bates routes: server registrations.
Reports already freeze evidence through the shared reporting service: capture flow.
The CLI already verifies a report ZIP and extracts its CSV. Use that single evidence artifact, without adding a second independently downloaded CSV protocol: existing CSV command.
Export planning, jobs, archive verification and download tickets already exist. Add only the adapters needed for this workflow: current download path.
Required behavior
1. One explicit selection. Capture the chosen current vault/document/version identities and content hashes. Validate them when the operation begins; a stale selection must be rejected visibly, never redirected to a new document head. Only explicitly chosen documents and attachment occurrences belong in the result. Reuse the existing snapshot/selection contracts wherever they fit.
2. A frozen, explainable report. Preserve the selected membership, keyword results, date decisions and coverage in the existing evidence bundle. A later source replacement, trash operation, or pruning does not invalidate a captured report. Online handles and downloads retain their existing 30-minute lifetime and are lost on daemon restart. History retains bounded request/summary receipts, not artifact bytes or reviewed date choices. Rerunning a saved selection checks that its versions are still current and available. Downloaded packets remain independently verifiable.
3. A verified export. Export the selected original/native bytes with the existing manifest, hashes and receipt machinery. Downloads must verify what is received and publish a complete local file atomically. Keep originals and version history intact. Preserve the existing Bates workflow; adding production packaging or new exchange formats is outside this first scope.
4. Bounded client access. Finish only the web, CLI and local-operator MCP operations needed to select/inspect, create or inspect a report, create or inspect an export, and download its result. Use the daemon and existing shared services. MCP creation remains an explicit write opt-in. Do not require a catalogue of every route or a new session/authorization framework to deliver this task.
Acceptance evidence
Use one small synthetic corpus with known document contents, dates, attachments and expected counts, exercised through the real daemon:
Select a subset and prove that the report and archive contain exactly those versions and explicitly selected attachments. Excluded documents must not appear.
Change a selected document before admission and observe a stale-selection response. Change it after report creation and verify that the completed report retains its original evidence and counts.
Change or remove a source after report capture and verify that the captured counts and downloads remain unchanged until expiry. Preserve the historical request/summary after source loss and backup/restore. After restart, old live handles are unavailable; a new run of a stale selection must fail rather than substitute a newer version.
Include missing text and ambiguous dates. Verify that coverage and date uncertainty remain visible and that reporting/export performs no provider work.
Verify the evidence ZIP offline and derive CSV from it. Compare known counts and exported file hashes independently; reject a modified artifact and leave no partially published destination file.
Exercise the affected recovery boundary: retained source identities and reusable history survive supported backup/restore and maintenance, and a supported report/export can be run afterward. Downloaded evidence bundles remain independently verifiable. Temporary handles have explicit expiry/unavailability behavior. Do not promise restored report artifact bytes, exact historical report regeneration, transient jobs or download tickets.
Demonstrate the bounded workflow through web, CLI and MCP. Run the repository-required checks in both SQLite modes and on supported native platforms before claiming the implementation complete; include actual synthetic UI captures with UI PRs.
Preserve released storage compatibility and existing public report/bundle contracts. Do not introduce new storage authority or a format version unless the selected behavior demonstrably needs it. Any unavoidable schema change must follow the repository's released-layout cutover rules.
Explicitly deferred
The full redacted-production lifecycle, custom policies, approval administration, privilege logs, reproduction and supplements.
New operation registries or capability matrices built for routes this workflow does not use.
Passage identity/federation, related-passage discovery, concept vocabularies, curated maps and refresh, and general index repair.
Automatic extraction/provider orchestration, additional file-format qualification, and the separate photo roadmaps.
These are deferred product decisions, not requirements that must be hidden inside the initial implementation.
A possible next scope: minimal PDF redaction
If redacted production is the next priority, define one separate outcome: select an ordinary native PDF from a fresh vault, prepare it through the real daemon, apply and review explicit page masks, preview the result, and retain/download one numbered redacted PDF with its sanitized text and provenance.
Reuse the existing PDF/redaction foundations and the generic policy, which does not require a custom approval or privilege-log workflow. Prove the source-preparation path first; a test fixture with preprepared production members is not an operator workflow. Scope the API and one operator interface before expanding to every surface. Before exposing delivery, verify redacted pixels and sanitized text together; retries and restart must preserve one number reservation, and backup/restore plus garbage collection must preserve retained bytes and provenance. Privilege administration, supplements, reproduction, and general package-format support remain separate decisions.
Delivery rules for the replacement work
The maintainers will implement from current main, reusing selected ideas or code only after review. Closing the queue does not nominate its final aggregate for wholesale import.
Selected reports (#726), CLI native exports with explicit release (#740), local MCP native exports (#749), local MCP search reports (#753), and CLI report inspection/download recovery (#754) are merged. These implement the bounded report/export adapters; history remains a receipt, not a promise that a live artifact is available.
The assessment at current main 2d100a274a548a9eb1e7f9aaef12eab478c78a1f found useful coverage in separate fixtures: selected text documents through MCP reports and native exports; report-history metadata round trips; retained supplied-text search after physical backup/restore; and CLI history/download behavior after restart. Seven focused tests covering these boundaries, CLI export release, and CLI backup/restore passed in both SQLite modes with the required fts5 tag. This evidence does not yet qualify one PDF selection through reporting, original-byte export, and a usable restored daemon.
The recommended next specification takes the narrow qualification outcomes from closed #518 and #530: use a small synthetic corpus, verify exact membership and known counts, preserve missing-text/date uncertainty, and demonstrate a new report/export after supported backup/restore. Distinguish restored sources and history from unavailable old report handles. Do not promise byte-identical regenerated reports or restored transient jobs and tickets. Use existing services and make any reproduced defect explicit before widening the implementation scope.
Additional catalog/text reads from #533 and retained-plan inspection from #583 remain optional follow-ups. Minimal PDF redaction remains a separate product scope after this acceptance boundary is understood.
Assess the complete local report/export workflow against the acceptance evidence above before selecting another product area. The production and discovery inventories remain deferred references. Keep one implementation PR active for the current outcome, merge only after maintainer review, and start the next against the merged result. Fold follow-up fixes into the active PR. If an outcome expands into a new subsystem, revise the scope before creating a new series.
The old roadmaps remain context; their complete delivery maps are not commitments to accept the closed stack. Detailed execution state belongs in the project issue ledger. This issue owns the public scope decision and links to the preserved proposal inventory.
@salmonumbrella — thank you for the work and the detailed proposals. We need to reset how this work is scoped and delivered.
We have closed all 260 of your PRs that were open in this repository at the start of this review. None was merged. The seven existing PRs from other contributors remain open. The volume, overlapping implementations, and dependencies make this queue impractical to review and maintain. We will move forward with a smaller, coherent scope that the maintainers can implement and review in manageable increments.
This is a decision about scope and delivery, not a claim that every proposal is wrong. The closed PRs remain available as references. Please pause additional PRs for these workstreams, and do not rebase or resubmit this stack while we agree on the replacement scope here.
Review overview
The inventory covers the 260 PRs open at the start of this review. All target
main. The source baseline is7bf6a59b, which matchedmainwhen checked.This is a highly overlapping queue, not 260 independent changes:
Complete inventories: 212 production proposals, 33 native-workflow proposals, and 15 discovery proposals. Every PR has a proposed increment, disposition, cumulative file count, and reviewed head. Review coverage: every PR description and complete changed-file inventory was catalogued; representative diffs, dependency relationships, and the current implementation were inspected. This is a scope and architecture review, not a line-by-line correctness audit or a claim that the proposed code passes tests.
Umbrella: finish the local document review-to-export workflow
Status: the cleanup in #721, sealed-snapshot load-file exports in #403, exact selected-document reports in #726, CLI native exports with explicit release in #740, local MCP native exports in #749, local MCP search reports in #753, and CLI report inspection/download recovery in #754 are merged. The next proposed slice is qualification of the existing report/export workflow with a small synthetic PDF corpus and physical backup/restore. Its scope and written specification remain to be reviewed; the complete acceptance assessment is still open.
The proposal inventory above records the original review. It is historical context, not a current merge checklist. The implemented report design supersedes this issue's original live-source-withdrawal rule: captured reports remain usable until their existing expiry, while a new run checks its selected sources again.
A local Docbank operator should be able to select a bounded set of documents, review the exact selected versions, produce a frozen keyword/date report with honest coverage, and download a verified archive of those same documents. The same bounded task should be usable from the web app, CLI, and local operator MCP.
Start with retained documents and already available renditions. A PDF without retained text can still be exported; the report must show the missing evidence rather than treating it as a zero-hit document. Creating a report or export must not start extraction, OCR, embeddings, or a hosted provider request.
Reuse the implementation already on main
Required behavior
1. One explicit selection. Capture the chosen current vault/document/version identities and content hashes. Validate them when the operation begins; a stale selection must be rejected visibly, never redirected to a new document head. Only explicitly chosen documents and attachment occurrences belong in the result. Reuse the existing snapshot/selection contracts wherever they fit.
2. A frozen, explainable report. Preserve the selected membership, keyword results, date decisions and coverage in the existing evidence bundle. A later source replacement, trash operation, or pruning does not invalidate a captured report. Online handles and downloads retain their existing 30-minute lifetime and are lost on daemon restart. History retains bounded request/summary receipts, not artifact bytes or reviewed date choices. Rerunning a saved selection checks that its versions are still current and available. Downloaded packets remain independently verifiable.
3. A verified export. Export the selected original/native bytes with the existing manifest, hashes and receipt machinery. Downloads must verify what is received and publish a complete local file atomically. Keep originals and version history intact. Preserve the existing Bates workflow; adding production packaging or new exchange formats is outside this first scope.
4. Bounded client access. Finish only the web, CLI and local-operator MCP operations needed to select/inspect, create or inspect a report, create or inspect an export, and download its result. Use the daemon and existing shared services. MCP creation remains an explicit write opt-in. Do not require a catalogue of every route or a new session/authorization framework to deliver this task.
Acceptance evidence
Use one small synthetic corpus with known document contents, dates, attachments and expected counts, exercised through the real daemon:
Preserve released storage compatibility and existing public report/bundle contracts. Do not introduce new storage authority or a format version unless the selected behavior demonstrably needs it. Any unavoidable schema change must follow the repository's released-layout cutover rules.
Explicitly deferred
These are deferred product decisions, not requirements that must be hidden inside the initial implementation.
A possible next scope: minimal PDF redaction
If redacted production is the next priority, define one separate outcome: select an ordinary native PDF from a fresh vault, prepare it through the real daemon, apply and review explicit page masks, preview the result, and retain/download one numbered redacted PDF with its sanitized text and provenance.
Reuse the existing PDF/redaction foundations and the generic policy, which does not require a custom approval or privilege-log workflow. Prove the source-preparation path first; a test fixture with preprepared production members is not an operator workflow. Scope the API and one operator interface before expanding to every surface. Before exposing delivery, verify redacted pixels and sanitized text together; retries and restart must preserve one number reservation, and backup/restore plus garbage collection must preserve retained bytes and provenance. Privilege administration, supplements, reproduction, and general package-format support remain separate decisions.
Delivery rules for the replacement work
The maintainers will implement from current
main, reusing selected ideas or code only after review. Closing the queue does not nominate its final aggregate for wholesale import.Selected reports (#726), CLI native exports with explicit release (#740), local MCP native exports (#749), local MCP search reports (#753), and CLI report inspection/download recovery (#754) are merged. These implement the bounded report/export adapters; history remains a receipt, not a promise that a live artifact is available.
The assessment at current main
2d100a274a548a9eb1e7f9aaef12eab478c78a1ffound useful coverage in separate fixtures: selected text documents through MCP reports and native exports; report-history metadata round trips; retained supplied-text search after physical backup/restore; and CLI history/download behavior after restart. Seven focused tests covering these boundaries, CLI export release, and CLI backup/restore passed in both SQLite modes with the requiredfts5tag. This evidence does not yet qualify one PDF selection through reporting, original-byte export, and a usable restored daemon.The recommended next specification takes the narrow qualification outcomes from closed #518 and #530: use a small synthetic corpus, verify exact membership and known counts, preserve missing-text/date uncertainty, and demonstrate a new report/export after supported backup/restore. Distinguish restored sources and history from unavailable old report handles. Do not promise byte-identical regenerated reports or restored transient jobs and tickets. Use existing services and make any reproduced defect explicit before widening the implementation scope.
Additional catalog/text reads from #533 and retained-plan inspection from #583 remain optional follow-ups. Minimal PDF redaction remains a separate product scope after this acceptance boundary is understood.
Assess the complete local report/export workflow against the acceptance evidence above before selecting another product area. The production and discovery inventories remain deferred references. Keep one implementation PR active for the current outcome, merge only after maintainer review, and start the next against the merged result. Fold follow-up fixes into the active PR. If an outcome expands into a new subsystem, revise the scope before creating a new series.
The old roadmaps remain context; their complete delivery maps are not commitments to accept the closed stack. Detailed execution state belongs in the project issue ledger. This issue owns the public scope decision and links to the preserved proposal inventory.