Usage

Pagemaster is intended to be an operator tool, not a reading or listening app. Grimmory and Audiobookshelf remain the consumption layer.

Current Lab App

Pagemaster now starts with a React/Vite operator console embedded in the Go server.

First visit:

1. Open the app URL.
2. Create the first operator account.
3. Continue to the operator console.

The current console starts empty after first-operator setup and expects configuration to happen inside the app. Configure roots, metadata providers, indexers, download clients, and incoming folders before scanning or searching.

The lab UI now follows the Readarr-inspired navigation target:

• Dashboard: latest organization plan, route cards, and operational status.
• Library: Authors, Books, and Unmapped Files sub-pages, plus source-root scanning.
• Add New: author, work, and edition metadata lookup plus request-target creation for authors, series, works, editions, and format-specific requests.
• Wanted: Missing, Search Results, and Manual Import sub-pages.
• Activity: Queue, History, and Blocklist sub-pages.
• Organization: review/apply view for the latest organization plan.
• Integrations: real manual incoming, SABnzbd, qBittorrent, and generic Newznab/Torznab/Prowlarr setup with redacted connection tests.
• Settings: Readarr-style Media Management, Profiles, Quality, Indexers, Download Clients, Metadata, General, and UI areas.
• System: service status, release posture, and lab operations.

These pages use authenticated APIs for persisted lab records. Source roots, metadata providers, download clients, indexers, and manual incoming sources can be configured from the app. Completed downloader jobs now appear as reviewable import/organization plans once the mapped local completed path can be scanned.

To add a wanted target, open Add New, enter the author, work, or edition name, and use Search metadata. Author results show provider, confidence, known works, aliases, and notes. Work and edition results show provider evidence such as title, contributors, dates, series, and identifiers. Choose Use to populate the request before adding the wanted item. Series and format-specific requests can still be typed directly while enrichment for those target shapes is built.

Wanted searches now persist ranked release candidates. Strong normalized release-name matches can appear as linked/high, while partial, weak, format-mismatched, or media-kind-mismatched results remain reviewable with warnings. The Wanted Search Results tab sorts indexer candidates by match strength and provides Download plus Reject review actions. Rejected candidates leave the active review list, cannot be sent to a download client, and can be restored from Activity -> Blocklist.

To validate an indexer, open Integrations, save a Newznab/Torznab/Prowlarr source, then use Test saved indexer or the Test action in Acquisition Sources. The app runs the search validation server-side with the stored API key and returns a redacted result count and failure category.

Current Prototype

From the repository root:

make prototype

Open http://127.0.0.1:8090 after the server starts. The app creates or opens its SQLite database, serves the embedded React console, and lets operators configure real lab roots and integrations from the browser. It does not seed fake wanted items, fake clients, or fixture scan data on fresh installs.

Useful CLI checks:

make test
make scan-fixtures
make check-organization
make check-large-scan
make check-persistence

make scan-fixtures scans fixtures/test-library and prints a JSON dry-run discovery report. It classifies supported media files, sidecars, partial downloads, and unknown files; groups candidates; extracts metadata evidence from paths and parseable sidecars; flags duplicate normalized identities; and builds a non-destructive dry-run import plan.

Current fixture summary:

• 27 files.
• 17 candidates.
• 11 importable candidates.
• 34 evidence records.
• 2 duplicate signals.
• 17 dry-run import plan actions.
• 2 partial files held as not importable.

Current organization dry-run summary:

• 17 organization actions.
• 4 ready to organize.
• 7 require review.
• 6 held.

Current apply behavior:

• Copy-only.
• Approval-gated.
• Bulk approval applies only to ready organization actions.
• Existing destination files block the operation; they are not overwritten.
• Unsupported operations, destructive operations, and conversion placeholders are blocked.
• Apply attempts are audited with source path, destination path, status, error, timestamps, retry count, and destructive flag.

Planned Operator Flow

1. Configure library roots and incoming folders.
2. Run a read-only scan.
3. Review discovered assets, metadata evidence, duplicates, and warnings.
4. Add wanted authors, books, series, editions, or formats.
5. Search acquisition sources and choose release candidates.
6. Hand downloads to configured external clients.
7. Let the completed-download poller scan the mapped local completed path.
8. Review completed downloads as import candidates and organization actions.
9. Preview the import and organization plan.
10. Apply approved copy operations.
11. Trigger downstream rescans where supported.

Acquisition is the center of gravity for the product. Manual incoming exists, but automation-first finding and making available is the main target.

Safety Defaults

• Source library roots are read-only by default.
• Import operations start as dry runs.
• Apply is copy-only until future move/delete/archive behavior is explicitly designed.
• Existing destinations are never overwritten automatically.
• Partial downloads are ignored or held.
• Duplicate candidates require operator review.
• Conflicts and low-confidence matches require operator review.