Roadmap SaaS claimable

SAAS-0001

in_progress

Complete the e-invoicing demo corpus to the strongest machine-verified state

The official French e-invoicing rollout begins on 1 September 2026, so the strongest near-term product proof is PPF/PDP, AIFE/annuaire, Chorus, FEC and VAT/accounting-treatment evidence parity.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

none

Acceptance criteria

• All active e-invoicing leases close with rotor receipts and no duplicate task ownership.
• Status page, coverage map, API guide and CLI docs show the same e-invoicing state.
• Meilisearch/live index and local corpus assets have a dated parity receipt.
• Scenario, answer, promotion, human-review, client-reliance and semantic flags remain false unless a separate launch gate proves otherwise.

Changelog closeout: Record the demo-ready machine state, counts, smoke receipts and remaining caveats.

SAAS-0002

done

Migrate rotor queue and lease state into Postgres

The file-backed rotor state is the largest orchestration risk under remote workers and many lanes.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

none

Acceptance criteria

• Postgres has canonical task, lease, heartbeat, closeout and event tables with migration receipt.
• Atomic claim-and-next replaces read-only next-task polling.
• Duplicate closeout submissions are idempotent by closeout_id or payload hash.
• File-backed JSON becomes export/cache only, not canonical state.

Changelog closeout: Record migration path, table counts, tests and rollback/export command.

SAAS-0003

done

Backfill the corpus warehouse and prove Meili/Warehouse parity

The warehouse is valuable only after it contains auditable corpus rows and can rebuild the live search index deterministically.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0002

Acceptance criteria

• Warehouse row counts, chunk counts and checksum counts are non-zero and dated.
• Meili live count, local full-index count and warehouse count differences are explained.
• A warehouse-to-Meili rebuild drill proves the live search index can be recreated from durable corpus state.
• Deletes, stale rows and corpus-family mappings have a deterministic conflict rule.
• Backfill receipt lists source files, rejected rows and retry plan.

Changelog closeout: Record parity counts and the source-of-truth rebuild command.

SAAS-0004

done

Make mtl-01 and mtl-03 first-class worker rosters

Worker lanes should not depend on tmux pane scraping or host-specific memory.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0002

Acceptance criteria

• Each lane has one canonical worker identity and scoped route permissions.
• mtl-01 and mtl-03 workers submit claims, heartbeats and closeouts through CLI/REST, not direct queue file mutation.
• The status page displays roster freshness without reading terminal history.
• Fallback model policy is visible per lane.

Changelog closeout: Record active lanes by host, profile and queue mode.

SAAS-0005

done

Implement lease expiry, dead-worker recovery and negative orchestration tests

A SaaS control plane must survive duplicate signals, dead lanes, partial receipts and network failures without human rescue.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0002, SAAS-0004

Acceptance criteria

• A dead worker lease is evicted after the configured heartbeat timeout.
• Two workers cannot own the same task unless the task explicitly permits shared work.
• Duplicate closeout and interrupted closeout tests pass.
• Readiness false flags are enforced at API, DB and CLI boundaries.

Changelog closeout: Record new tests and the reaper service status.

SAAS-0006

done

Keep public status, coverage, CLI docs and API docs auto-synchronized

External reviewers now use the status page as diligence evidence; stale or contradictory counters hurt credibility.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0001

Acceptance criteria

• Every rotor closeout can trigger status refresh without interrupting active TUI agents.
• bureau-status.html, bureau-api.html, CLI docs and coverage map cite the same counts.
• Public pages identify local-only vs live-indexed deltas without implying deployment failure.
• Roadmap tasks link to receipts and move to changelog only when acceptance is met.

Changelog closeout: Record the automation trigger and latest published receipt.

SAAS-0007

done

Harden security boundaries for remote workers and warehouse access

The current stage is acceptable with static IP allowlists, but SaaS needs scoped tokens and revocation.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0004

Acceptance criteria

• Each worker token is scoped to heartbeat, claim, closeout and artifact checksum routes.
• Non-allowlisted Postgres routes fail closed and are tested.
• Secrets are absent from public docs and receipts.
• Token rotation and revocation runbooks exist.

Changelog closeout: Record token scopes, deny-path tests and rotation procedure.

SAAS-0008

done

Add backup, restore and disaster-recovery drills for Postgres, Meili and artifacts

Corpus value becomes real only when it can be restored without replaying weeks of ingest work.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0003

Acceptance criteria

• Backups cover Postgres, Meili index config/data and mtl-02 corpus artifacts.
• A restore drill creates a dated receipt with counts and checksums.
• RPO/RTO targets are documented for prototype and SaaS stages.
• Backups do not expose secrets in public status artifacts.

Changelog closeout: Record backup schedule and latest restore receipt.

SAAS-0016

done

Publish claimable roadmap and changelog workflow

The team needs one visible plan with task numbers, claim state and a clear route from roadmap to changelog.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

none

Acceptance criteria

• A public roadmap page exists and links from API/status surfaces.
• Each roadmap item has a SAAS-#### task number, claim state, dependencies and acceptance criteria.
• Initial claims are recorded without preempting current e-invoicing leases.
• Future completions have a documented changelog closeout rule.

Changelog closeout: Record this roadmap publication, receipt and static publish path.

SAAS-0017

done

Build one atomic status snapshot for all public and diligence surfaces

Claude's review flagged independently timed status reads as a source of confusing count skew for buyers and operators.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0002, SAAS-0003, SAAS-0006

Acceptance criteria

• One dated JSON snapshot includes warehouse counts, Meili counts, active leases, stale leases, closeouts and false readiness flags.
• bureau-status.html, bureau-roadmap.html and API/status docs cite the same snapshot id.
• A validation command fails if public pages would publish mixed timestamps or contradictory counts.
• Snapshot generation is low-priority and does not run broad repository scans.

Changelog closeout: Record the canonical snapshot path, validation command and first no-skew publish receipt.

SAAS-0018

done

Quarantine ad-hoc scripts and consolidate supported operations into legipro-cli

The external review identified script sprawl as the main elegance and maintainability drag after the control-plane hardening.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0006, SAAS-0017

Acceptance criteria

• A script inventory maps supported operational flows to `python3 -m legipro_cli.main ...` commands.
• Unsupported historical scripts are documented as receipts/helpers/attic candidates and excluded from new lane prompts.
• CLI help documents the supported rotor, warehouse, docs, status and diligence commands.
• No historical artifact or receipt is removed during quarantine.

Changelog closeout: Record the script inventory path, CLI help update and excluded historical directories.

SAAS-0046

done

Prepare the e-invoicing-first partner/product screening memo

The right first ask is a product/ISV/API screen around the September 2026 e-invoicing workflow, not COO/GM sponsorship or a broad architecture pitch.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0037, SAAS-0038

Acceptance criteria

• A two-page memo exists that can be read by a non-technical executive assistant and routed to product/ISV/API owners.
• The memo proposes one narrow e-invoicing/VAT/accounting-treatment proof workflow rather than a broad platform pitch.
• The memo uses the official 1 September 2026 e-invoicing rollout as the market urgency and does not say the legal trigger is October.
• The memo states that LegiPro has no paying users/ARR, Scenario is locked, semantic search is planned, professional certification is not claimed and human/professional review remains a boundary.
• The memo includes the exact ask: 30-minute partner/product screening and sandbox/API access path, not CEO/COO sponsorship.

Changelog closeout: Record the Cegid memo path, source evidence and unchanged executive-escalation boundary.

SAAS-0047

done

Build the first e-invoicing/VAT proof-of-fit adapter stub

Partner API access often requires credentials and product-owner approval, so LegiPro needs a credential-free e-invoicing/VAT proof fixture before asking for sandbox access.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0034, SAAS-0035, SAAS-0036, SAAS-0046

Acceptance criteria

• A repo-only adapter stub exists with no embedded credentials and no live network calls by default.
• The stub models partner-style auth/header assumptions, company-file context and retry policy without claiming approved platform access.
• Fixture examples cover one low-risk e-invoicing/VAT path: source-backed review dossier export mapped to a document/workspace handoff.
• Tests prove missing credentials fail closed and public/demo LegiPro tokens cannot mutate third-party systems or rotor state.

Changelog closeout: Record the adapter stub paths, fixture names, tests and explicit no-live-Cegid-call boundary.

SAAS-0051

done

Publish the strategic accounting API integration map

Strategic interest is easier to provoke when LegiPro can show exactly how it could embed into the full French accounting platform ecosystem without requiring the buyer to adopt the Bureau UI.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0037, SAAS-0046

Acceptance criteria

• The map covers Cegid Loop, Cegid Expert/Quadra, Cegid XRP, Sage Accounting, Sage Active, Pennylane, EBP, Odoo, Abby, Inqom, ACD/i-Suite, RCA/MEG, Tiime, Yooz, Macompta.fr, Sellsy, Dext, Indy and Axonaut.
• Each vendor row records API/doc posture, auth/access signal, LegiPro wedge and uncertainty.
• The document is included as a roadmap source and does not claim live third-party API access or approved partnerships.
• The closeout keeps all ARR, Scenario, professional-certification and client-reliance boundaries unchanged.

Changelog closeout: Record the strategic API map path, sources used and unchanged third-party partnership boundary.

SAAS-0052

done

Build the shared e-invoicing-first buyer adapter fixture harness

Per-vendor stubs should consume the same LegiPro review/export payload so strategic demos prove a repeatable integration pattern, not one-off glue.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0035, SAAS-0036, SAAS-0041, SAAS-0051

Acceptance criteria

• A shared adapter fixture schema exists for request context, credential posture, dry-run target, idempotency key, source refs and output artifact refs.
• The harness fails closed when credentials are absent and defaults to no live network calls.
• Tests prove demo/public LegiPro tokens cannot call protected rotor routes or third-party live APIs through the harness.
• Fixture outputs can be attached to a buyer screening pack without exposing secrets or claiming certification.

Changelog closeout: Record the shared adapter harness paths, fixture schema, tests and no-live-third-party-call boundary.

SAAS-0057

done

Ship the September 2026 e-invoicing/VAT no-credential proof fixture

The reviewer correctly says the next credibility jump is not more architecture: it is a single working partner-shaped e-invoicing/VAT fixture tied to the official 1 September 2026 rollout and requiring no live credentials.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0038, SAAS-0041, SAAS-0052

Acceptance criteria

• A runnable fixture command or test exists for one platform-shaped flow and requires no third-party credentials.
• The fixture input includes partner product context, workspace/tenant scope, professional question and relevant facts.
• The fixture output includes answerability status, cited source refs, applicability/date notes, missing facts or risk flags, draft dossier/export id, audit id and partner-shaped handoff payload.
• The fixture can be explained in one paragraph to a non-technical executive assistant and in one packet to a product/API owner.
• The fixture fails closed for absent credentials and emits a receipt proving no live third-party API call occurred.
• The artifact is suitable for a 30-minute partner/product screening and preserves all no-partnership, no-client-reliance, no-human-review-complete and no-professional-certification boundaries.

Changelog closeout: Record the first proof fixture command, sample payload, receipt, tests and no-live-third-party-call boundary.

SAAS-0059

done

Publish the e-invoicing-first screening note and public docs update

The first outreach should be readable by a non-technical executive assistant and should make the September 2026 e-invoicing/VAT workflow the obvious route into product/partner screening.

Phase

Now

Priority

P0

Owner

/rook-410

Depends on

SAAS-0046, SAAS-0057, SAAS-0058

Acceptance criteria

• The sendable note names the official 1 September 2026 e-invoicing rollout and avoids the incorrect October-as-legal-trigger wording.
• The first paragraph is non-technical and explains partner value before API surfaces.
• Public roadmap/API docs identify the next proof as e-invoicing/VAT/accounting-treatment review, not a broad chatbot or architecture memo.
• The C4 map shows the e-invoicing/VAT proof fixture as the current near-term partner-integration wedge.
• Boundaries remain explicit: no partnership, no live third-party credentials, no paying users/ARR, no client-ready reliance, no certified professional review.

Changelog closeout: Record updated outreach note, public docs, C4 source path and unchanged readiness/professional boundaries.

SAAS-0009

done

Publish OpenAPI/GraphQL/MCP contracts and partner onboarding proof

Partner diligence needs machine-readable API contracts, not only narrative docs.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0002, SAAS-0004

Acceptance criteria

• OpenAPI includes /v0, /v1/search, /v1/retrieve and /v0/rotor bounded routes.
• GraphQL and MCP examples are smoke-tested with demo tokens.
• The API page separates active bounded surfaces from planned Scenario/semantic work.
• Partner one-pager links to CLI verification commands.

Changelog closeout: Record spec paths and smoke receipt.

SAAS-0010

done

Choose and benchmark the French legal/accounting embedding strategy

Semantic search can be a moat only if retrieval quality is proven on French legal/accounting questions.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0003

Acceptance criteria

• Embedding dimensions are model-versioned, not hard-coded to one provider.
• Benchmark includes BOFiP, PCG/ANC, URSSAF, Code de commerce and e-invoicing queries.
• Precision/recall and failure examples are documented.
• semantic_search_active remains false until the activation gate passes.

Changelog closeout: Record selected model, rejected models, cost estimate and activation blocker.

SAAS-0011

done

Unlock Scenario only after corpus, retrieval and guardrail gates pass

Scenario is the product payoff, but enabling it before data and guardrails are ready would create professional reliance risk.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0001, SAAS-0003, SAAS-0005, SAAS-0010

Acceptance criteria

• Scenario has fixture, graph, RAG, retrieval and source-card gates per corpus family.
• No client-usable Scenario conclusion is exposed before the launch gate.
• The page explains Scenario locked vs review/demo-mode without ambiguity.
• If all machine gates pass, the final professional-review switch remains separate.

Changelog closeout: Record Scenario gate matrix and whether it remains locked.

SAAS-0012

done

Build SaaS organization, workspace, RBAC, quota and billing foundations

A buyer or partner needs tenant separation, usage controls and commercial packaging before production pilots.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0007, SAAS-0009

Acceptance criteria

• Tenant/workspace auth paths are documented and smoke-tested.
• Demo tokens are clearly separated from partner tokens.
• Rate limits and usage logs are visible for REST, GraphQL, MCP and CLI.
• No paying-users or ARR claim is made until real contracts exist.

Changelog closeout: Record tenant model and demo/partner boundary.

SAAS-0013

done

Create the operator dashboard for queue, leases, workers, parity and blockers

tmux is useful for humans, but it cannot be the nervous system of a SaaS corpus factory.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0002, SAAS-0004, SAAS-0005

Acceptance criteria

• Dashboard reads canonical Postgres/warehouse state, not terminal buffers.
• It shows stale leases and next action for every lane.
• It links to latest artifact checksums and receipts.
• It stays public-safe or has explicit auth separation.

Changelog closeout: Record dashboard URL and current health snapshot.

SAAS-0015

done

Refresh the diligence pack and external narrative from live evidence

External reviewers should see working APIs, corpus counts, rights caveats and roadmap status without stale valuation claims.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0006, SAAS-0009

Acceptance criteria

• The pack cites live public pages and local receipts.
• It does not claim ARR, paying users, trademark clearance, legal opinion or client-ready Scenario.
• It includes public demo bearer API tests for reviewers.
• Known limitations sit in a clear final section instead of reading like a wall of negatives.

Changelog closeout: Record pack path, receipt and public pages used.

SAAS-0019

done

Containerize one reference worker lane as the pets-to-cattle proof

The target SaaS architecture is credible only after one worker can be recreated without tmux history or host-local state.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0004, SAAS-0007, SAAS-0018

Acceptance criteria

• A fresh worker can register, claim, heartbeat and close out a safe task using only documented configuration.
• The worker writes no canonical state outside the control-plane API and artifact output paths.
• The same container image can run on mtl-01 or mtl-03 with host-specific secrets injected externally.
• A rollback path returns the lane to the existing Hermes/tmux posture if needed.

Changelog closeout: Record image/build path, smoke receipt, rollback command and remaining non-container lanes.

SAAS-0020

done

Publish a current diligence-room pointer and one-page buyer narrative

Reviewers should not have to infer the current asset story from many dated docs and terminal receipts.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0006, SAAS-0015, SAAS-0017

Acceptance criteria

• A single `docs/diligence/current.md` points to the latest active documents and receipts.
• The one-pager frames LegiPro as an asset-sale/platform-readiness story, not an ARR valuation.
• Negative caveats are grouped in a clear limitations section rather than scattered as alarm copy.
• Public docs link to current API/status/roadmap evidence without exposing secrets.

Changelog closeout: Record diligence pointer path, one-pager path and source receipts used.

SAAS-0021

done

Execute the staged SaaS substrate migration plan

Claude's target architecture argues the gap is substrate re-platforming, not product rewrite; the roadmap needs that work claimable.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0017, SAAS-0018, SAAS-0019

Acceptance criteria

• Phase 0 hygiene, Phase 1 containerization and Phase 2 managed/HA Postgres have explicit owners, receipts and rollback gates.
• Secrets move from host files into a documented KMS/Vault-compatible path before enterprise pilots.
• Gateway, SSO, telemetry and SLO tasks are sequenced after data/control-plane stability.
• The moat remains corpus/trace/guardrail quality; infrastructure migration does not widen readiness claims.

Changelog closeout: Record phased migration status and which SaaS substrate risks remain open.

SAAS-0022

done

Archive closed rotor task history out of the hot claim table

External review flagged the large done_machine_safe_delta history as buyer-visible operational drag; hot claim scans should stay small without losing audit evidence.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0002, SAAS-0005, SAAS-0018

Acceptance criteria

• `rotor_tasks_archive` exists with archived rows and false readiness constraints.
• `legipro rotor db-archive-done-tasks` is dry-run by default and rejects live statuses such as `leased`.
• At least one bounded execute batch archives closed rows without touching active leases.
• CLI docs and public API docs document the archive command and audit boundary.

Changelog closeout: Record archive counts, command, tests and remaining archive candidates.

SAAS-0023

done

Retire or quarantine dead frontend stubs for buyer-facing repo hygiene

External review flagged historical frontend stubs and a large scripts directory as sprawl; SAAS-0018 narrowed script operations, but visible dead UI surfaces still need explicit cleanup.

Phase

Next

Priority

P2

Owner

/rook-410

Depends on

SAAS-0018, SAAS-0020

Acceptance criteria

• Each legacy frontend stub has a disposition: active, redirected, archived, or deleted.
• Public navigation and docs do not link to retired stubs.
• Any removed/redirected public page has a rollback note and no broken internal links.
• The script inventory remains the operational source for CLI-first processing.

Changelog closeout: Record stub disposition counts, changed routes/files and rollback notes.

SAAS-0024

done

Define and smoke the Review Answer Runtime contract

The buyer-facing product should return a current, cited, reviewable answer with missing facts, risk flags, and an export bundle, not just raw search results.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0009, SAAS-0012

Acceptance criteria

• The contract includes answerability status, applicability, effective dates, sources, missing facts, risk flags, export_bundle_id and audit_id.
• At least one smoke fixture returns `insufficient_evidence` or `conflicting_sources` when sources do not support a safe answer.
• The public API guide documents this as a bounded review workflow, not a certified professional conclusion.
• Scenario, answer-ready, promotion, human-review, client-reliance and semantic flags remain false.

Changelog closeout: Record contract path, smoke fixtures and false-readiness boundary.

SAAS-0025

done

Separate Partner Product API, AI Tool Runtime and Internal Control Plane docs

Reviewers should not see buyer-facing product flows adjacent to queue minting and worker closeouts without a clear internal boundary.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0007, SAAS-0009, SAAS-0024

Acceptance criteria

• API docs separate product endpoints, MCP tools and internal rotor worker routes.
• Worker tokens cannot call partner-only product mutations or queue-minting commands.
• Partner examples use product/search/review/export flows, not rotor control-plane flows.
• The architecture map and public API page use the same surface names.

Changelog closeout: Record docs paths, route-scope checks and architecture map update.

SAAS-0026

done

Upgrade retrieval from search access to decision-grade evidence

Premium accounting/legal answers need authority, temporal validity, contradiction handling and citation envelopes, not keyword hits alone.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0003, SAAS-0010, SAAS-0024

Acceptance criteria

• Retrieval fixtures cover BOFiP, PCG/ANC, URSSAF, Code de commerce and e-invoicing examples.
• Every returned answer candidate carries source IDs, passage IDs, artifact IDs and date/asOf metadata.
• Older/superseded sources are marked or demoted in fixtures.
• semantic_search_active remains false until the separate SAAS-0010 activation gate passes.

Changelog closeout: Record retrieval fixtures, metrics and activation boundary.

SAAS-0027

done

Add product observability for answer, retrieval, export and partner value

Receipts are good diligence evidence, but daily SaaS operation needs live metrics around user value and degraded behavior.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0013, SAAS-0017, SAAS-0024

Acceptance criteria

• A status/dashboard artifact shows p50/p95 search/review/export latency and error counts.
• Answerability, insufficient-evidence and conflicting-source rates are tracked without private prompt leakage.
• Per-tenant cost units, throttles and denied-scope attempts are visible to operators.
• Metrics feed docs/status snapshots without broad repository scans.

Changelog closeout: Record metrics schema, dashboard path and snapshot receipt.

SAAS-0028

done

Productize export bundles and revisioned dossiers

For professional users and API buyers, the durable cited dossier may be more valuable than the chat/search interaction.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0012, SAAS-0024

Acceptance criteria

• Export bundle schema includes tenant/workspace, source IDs, passage IDs, dates, caveats, revision id and audit id.
• A buyer-branded export fixture is generated without exposing private prompts or secrets.
• Failed export returns a queued job id or clear retry state rather than blocking the review workflow.
• Exports remain review-gated and do not imply client reliance or professional certification.

Changelog closeout: Record export schema, fixture output and tenant/audit fields.

SAAS-0029

done

Expose source freshness, supersession and dossier impact analysis

The corpus factory becomes a moat when the product can tell which sources changed and which saved work may need review.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0003, SAAS-0026, SAAS-0028

Acceptance criteria

• Source records expose last_checked_at, last_changed_at, content hash, valid_from/valid_until and supersession status where known.
• A fixture shows a changed source and the affected saved dossier/export ids.
• Public docs explain freshness as product intelligence, not a professional review claim.
• Stale-source warnings appear before answer/export confidence fields.

Changelog closeout: Record source freshness fields, impact fixture and public docs update.

SAAS-0030

done

Define and test degraded-mode behavior for product runtime dependencies

Buyers test failure behavior; a useful system should degrade into source packs, queued exports or last-known-good corpus rather than fail ambiguously.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0013, SAAS-0024, SAAS-0027

Acceptance criteria

• Meili-down, warehouse-slow, assistant-unavailable, export-unavailable, worker-down and stale-index fixtures exist.
• Each degraded mode returns a clear status, warning and next action or job id.
• The status page and API docs identify last-known-good corpus/index timestamps.
• No degraded mode widens Scenario, answer-ready, promotion, client-reliance or professional-certification flags.

Changelog closeout: Record degraded-mode fixtures, API behavior and status docs update.

SAAS-0031

done

Move recurring CLI operations into scheduled jobs, admin APIs and CI gates

The CLI is excellent proof and break-glass tooling, but production paths should not depend on a human operating terminal commands.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0006, SAAS-0013, SAAS-0018, SAAS-0027

Acceptance criteria

• Each recurring CLI command has a scheduled/admin/CI owner or explicit break-glass label.
• Scheduled jobs write the same receipts as CLI runs and are visible in telemetry.
• Manual CLI use remains possible for local QA and rollback.
• No scheduled job performs broad repository scans or mints queue rows outside mtl-01.

Changelog closeout: Record scheduled/admin/CI mapping and first automated receipt.

SAAS-0032

done

Roadmap partner SDKs and generated client workflow

Partners should be able to integrate LegiPro quickly from their own product surfaces without copying curl snippets or learning rotor internals.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0009, SAAS-0024, SAAS-0025, SAAS-0028, SAAS-0030

Acceptance criteria

• Public roadmap and API docs list SDKs as planned/not shipped, with TypeScript/Node as the first target and Python as the second target.
• SDK generation depends on a stable OpenAPI/contract artifact and does not hand-maintain business logic outside REST, GraphQL, MCP and Review Runtime contracts.
• Examples cover search, retrieve, review-preview, export bundle and MCP tool calls with tenant/workspace/cost-unit headers.
• SDK docs warn against embedding bearer keys in browser/mobile clients and preserve Scenario, answer-ready, client-reliance and semantic-search false boundaries.

Changelog closeout: Record SDK roadmap, generated-client source, examples and contract-test receipt.

SAAS-0033

done

Publish static OpenAPI snapshot for partner SDK codegen

Partner SDK generation needs a machine-readable contract before the live /openapi.json route is promoted.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0009, SAAS-0025, SAAS-0032

Acceptance criteria

• A public static OpenAPI JSON asset exists and parses as OpenAPI 3.1.
• The snapshot covers /v0/search/health, /v0/search, /v1/search, /v1/retrieve, /graphql, /mcp and protected /v0/rotor worker routes.
• The API contract and API guide point to the static asset while still saying /openapi.json is not a live JSON route.
• The snapshot keeps SDK status planned/not shipped and preserves Scenario, answer-ready, client-reliance, semantic-search and professional-certification false boundaries.

Changelog closeout: Record static OpenAPI snapshot, asset URL, contract wiring and tests.

SAAS-0034

done

Publish partner API quickstart pack

A buyer should be able to run the first server-side integration checks without reading the whole API guide.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0009, SAAS-0025, SAAS-0033

Acceptance criteria

• A public quickstart asset exists for server-side partner integration.
• The quickstart covers health, search, retrieve, GraphQL and MCP tool-call flows.
• The API contract and API guide link the quickstart alongside the static OpenAPI snapshot.
• The quickstart forbids browser/mobile bearer-token exposure and product-token rotor calls.
• Scenario, answer-ready, client-reliance, semantic-search and professional-certification flags remain false.

Changelog closeout: Record partner quickstart asset, public URL, contract wiring and tests.

SAAS-0035

done

Ship the first generated TypeScript/Node partner SDK beta

The SDK roadmap needs a concrete first delivery so partner teams can integrate LegiPro from Node services without assembling thin wrappers by hand.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0032, SAAS-0033, SAAS-0034

Acceptance criteria

• A generated TypeScript/Node beta client exists with a documented package/version source and no hand-maintained business logic fork.
• Server-side examples cover search, retrieve, review-preview, export bundle preview and MCP tool calls with tenant/workspace/cost-unit headers.
• Contract tests prove the generated client matches the static OpenAPI and partner contract artifacts and reject browser/mobile bearer-token usage.
• The public roadmap, API guide and partner contract asset identify the TypeScript/Node SDK as the first delivery target while keeping SDK status pre-GA and all readiness/professional flags false.

Changelog closeout: Record generated TypeScript/Node SDK beta package, examples, contract-test receipt and public docs update.

SAAS-0038

done

Implement the Review Runtime kernel inside the current modular monolith

External reviews now agree the next multiplier is a professional review workflow engine, not more standalone surface area or more infrastructure prose.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0024, SAAS-0025, SAAS-0026, SAAS-0028, SAAS-0030

Acceptance criteria

• The current Product API gains in-repo runtime modules for review orchestration, retrieval, applicability, answer contract, citation verification, dossier handling and audit emission.
• The implementation reuses existing search/retrieve/export contracts and does not create a second business-logic brain beside REST, GraphQL, MCP and CLI.
• Exactly two LLM stages are allowed in the runtime path: request normalization and answer synthesis; citation verification remains deterministic/mechanical.
• The delivery may remain preview/private and does not require a live public /v1/review route; Scenario, answer-ready, promotion, human-review, client-reliance, semantic-search and professional-certification flags remain false.

Changelog closeout: Record the runtime module paths, tests, and the first bounded preview wiring without widening any readiness claim.

SAAS-0039

done

Add snapshot-pinned review requests, applicability checks and refusal remedies

A buyer-grade review workflow must be replayable against a dated corpus state and must know when to refuse, what is missing, and which sources conflict.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0024, SAAS-0026, SAAS-0029, SAAS-0038

Acceptance criteria

• Review requests can pin corpus/index snapshot IDs as inputs, not only receive them as outputs.
• Applicability checks cover jurisdiction, effective dates, supersession, source hierarchy and missing-fact detection with deterministic receipts or fixtures.
• Refusal taxonomy is explicit: insufficient_evidence requires missing_facts with remedies, conflicting_sources requires contradiction pairs with authority_rank and remedy guidance, and partially_answerable remains distinct from answerable.
• A validate/confirm-refute workflow exists as a bounded mode for checking a proposed treatment without claiming professional certification or client reliance.

Changelog closeout: Record snapshot-pinned request/response examples, applicability checks, validate-mode proof and refusal-remedy fixtures.

SAAS-0040

done

Build the golden review eval set and runtime audit sink

The review runtime only becomes diligence-grade when every run is measurable and regressions are caught against labeled professional cases, including refusal and contradiction scenarios.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0027, SAAS-0038, SAAS-0039

Acceptance criteria

• A labeled golden review set exists with answerable, partially_answerable, insufficient_evidence, conflicting_sources and validate-mode cases.
• Runtime audit events record audit_id, tenant/workspace scope, latency, answerability status, citation coverage, missing-fact count, contradiction count and snapshot IDs without storing raw private prompts in public-safe assets.
• CI or CLI gates fail closed when the review runtime regresses on golden answerability/refusal/citation checks.
• The public observability/docs surfaces describe this as bounded quality evidence, not a claim of human review, client reliance or professional certification.

Changelog closeout: Record the golden eval-set paths, runtime audit schema, gating command and the first passing receipt.

SAAS-0043

done

Publish a current/planned/target architecture legend and readiness matrix

External reviewers now understand the C4 better, but they still need a one-glance legend showing what is live today, what is planned inside the current monolith, and what belongs to the target SaaS substrate.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0025, SAAS-0038

Acceptance criteria

• The public architecture/C4 surface includes a visible legend for current, planned and target components.
• Meilisearch is explicitly presented as a derived cache and the corpus warehouse as the durable source of truth in both diagram and adjacent text.
• A readiness matrix distinguishes current active, current bounded, planned and target SaaS items without widening any readiness claim.
• Scenario, answer-ready, client-reliance, semantic-search and professional-certification boundaries remain false and are repeated beside the matrix.

Changelog closeout: Record the legend/matrix assets, public URLs and the unchanged false-readiness boundary.

SAAS-0044

done

Add dedicated buyer integration and corpus-factory architecture views

The strongest acquirer story is now the embed-without-UI path and the receipt-backed corpus factory flow; those deserve first-class diagrams instead of being implied across one larger map.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0025, SAAS-0043

Acceptance criteria

• A public 'Partner Integration Without UI Adoption' architecture view exists and shows buyer product -> REST/GraphQL/MCP -> evidence/dossier outputs.
• A public 'Corpus Factory and Readiness Gates' architecture view exists and shows worker claim/heartbeat/closeout, warehouse/index separation, backup proof and false-readiness gates.
• Both views stay aligned with the canonical workspace DSL and are linked from the API or architecture surfaces without inventing a second source of truth.
• The views remain bounded and do not imply Scenario launch, professional sign-off or semantic-search activation.

Changelog closeout: Record the new rendered views, their public links and the DSL/source files they derive from.

SAAS-0048

done

Create the Cegid technical screening pack

A partner/product reviewer needs one narrow package: how to test LegiPro, what Cegid APIs it could map to, what is active, what is not and what evidence proves it.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0045, SAAS-0046, SAAS-0047

Acceptance criteria

• A single Cegid screening pack exists with index, links and local/public evidence paths.
• The pack maps LegiPro REST/GraphQL/MCP/SDK surfaces to likely Cegid Loop/partner API touchpoints without claiming an approved Cegid partnership.
• The pack includes runnable local commands for LegiPro API smoke, SDK example smoke and Cegid adapter fixture smoke.
• The pack repeats the no-SLA/no-ARR/no-client-reliance/no-professional-certification boundaries.

Changelog closeout: Record the Cegid screening pack path, commands, tests and public-safe publication state.

SAAS-0049

done

Run the e-invoicing/VAT partner proof path end to end

A credible screening call should show one professional workflow tied to the September 2026 rollout, not just architecture: question or document input, source-backed review packet, draft dossier/export and partner-shaped handoff fixture.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0039, SAAS-0041, SAAS-0047

Acceptance criteria

• The demo path uses one bounded workflow and includes screenshots or command receipts from public-safe LegiPro surfaces.
• The output includes answerability status, sources, applicability, missing facts/risks if any, draft dossier/export id and audit id.
• The partner adapter fixture consumes the export/dossier metadata without live third-party credentials.
• The demo does not claim Scenario launch, client reliance, human review, semantic search activation or a third-party partnership.

Changelog closeout: Record the Cegid-style pilot demo receipt, fixture output and screenshots or public-safe command evidence.

SAAS-0050

done

Define the Cegid escalation gate

COO/GM presentation should be a gated escalation after partner/product validation, not the first outreach step.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0046, SAAS-0048, SAAS-0049

Acceptance criteria

• A Cegid escalation checklist exists with required evidence for Partner/Product, AI/Product, Startup Program and COO/GM routes.
• The checklist states that COO/GM escalation is blocked until at least one product/partner owner validates fit or requests senior sponsorship.
• The checklist includes the exact diligence artifacts to send at each stage and the artifacts to withhold from first contact.
• The checklist stays aligned with current product boundaries: no ARR, no paying users, Scenario locked and professional reliance not certified.

Changelog closeout: Record the Cegid escalation gate path and the evidence threshold for executive-ready status.

SAAS-0053

done

Ship first-wave self-serve adapter stubs

After one proof fixture exists, Cegid Loop/Expert, Sage, Pennylane, Odoo, Abby and Inqom have enough public API detail to support additional no-credential stubs that demonstrate LegiPro as an embeddable source-review engine.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0052

Acceptance criteria

• At least three first-wave adapters exist and consume the shared adapter fixture harness.
• The first-wave candidate list is explicit: Cegid Loop/Expert, Sage Accounting/Active, Pennylane, Odoo, Abby and Inqom.
• Each adapter maps one bounded LegiPro output to a plausible vendor object flow such as document handoff, invoice/customer sync, dossier/context sync or accounting-entry handoff.
• Each adapter includes public-doc citations, dry-run sample output, fail-closed credential behavior and tests.
• No adapter makes live API calls unless an explicit non-default credentialed mode is later added and separately documented.

Changelog closeout: Record the first-wave adapter paths, sample outputs, tests and no-live-call boundary.

SAAS-0054

ready

Create partner-gated strategic adapter briefs

Some of the most strategically useful buyers have gated or partial public API docs; LegiPro should still show the intended integration shape without inventing endpoint details.

Phase

Next

Priority

P1

Owner

unclaimed

Depends on

SAAS-0051

Acceptance criteria

• Each brief states verified public docs, missing access details, likely integration objects and exact partner/sandbox ask.
• The briefs clearly separate public-doc facts, inference and unresolved access questions.
• The partner-gated list is explicit: EBP, Cegid XRP, ACD/i-Suite, RCA/MEG, Sellsy, Dext, Tiime, Yooz, Macompta.fr, Indy and Axonaut.
• No brief claims an approved partnership, live credential, customer integration, SLA or professional reliance.

Changelog closeout: Record the partner-gated brief paths, vendors covered and unresolved access questions.

SAAS-0056

done

Create per-platform value cards for the full accounting ecosystem

The integration roadmap should be readable by any mapped accounting platform, not only a single strategic contact.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0051, SAAS-0052

Acceptance criteria

• Value cards exist for Cegid Loop, Cegid Expert/Quadra, Cegid XRP, Sage Accounting, Sage Active, Pennylane, EBP, Odoo, Abby, Inqom, ACD/i-Suite, RCA/MEG, Tiime, Yooz, Macompta.fr, Sellsy, Dext, Indy and Axonaut.
• Each card states client value, likely object flow, integration readiness tier, public-doc confidence and unresolved access questions.
• The cards avoid vendor-specific overclaims and can be reused in outbound notes to multiple platforms.
• The cards preserve all no-partnership, no-live-third-party-call, no-ARR, no-client-reliance and no-professional-certification boundaries.

Changelog closeout: Record the per-platform value card paths, vendors covered and reusable outbound/public-safe status.

SAAS-0058

done

Create the e-invoicing proof and first-screening comparison pack

The outreach should create urgency from the September 2026 rollout, not pressure tactics: early product screens can shape the proof workflow while it is still concrete and not yet a generic adapter kit.

Phase

Next

Priority

P1

Owner

/rook-410

Depends on

SAAS-0051, SAAS-0057

Acceptance criteria

• The pack explains the early-screening advantage without threatening a bidding process or claiming competing partnerships.
• The pack shows which integration decisions remain shapeable before the generic adapter kit hardens.
• The pack includes the first proof fixture receipt and the full vendor map.
• The pack is reusable for Cegid, Sage, Pennylane, EBP, Odoo, Abby, Inqom, ACD/RCA/Tiime/Yooz/Macompta/Sellsy/Dext/Indy/Axonaut-style conversations.

Changelog closeout: Record the first-mover proof pack path, included fixture evidence and public-safe outbound boundary.

SAAS-0014

done

Design multi-country corpus adapters for France, UK and Canada

Country expansion is cheaper if source ownership, citation, date validity and authority tiers are modeled now.

Phase

Later

Priority

P2

Owner

/rook-410

Depends on

SAAS-0003, SAAS-0010, SAAS-0011

Acceptance criteria

• Adapter schema covers source owner, license, authority tier, date validity and jurisdiction.
• FR behavior is not hard-coded into generic retrieval or Scenario logic.
• UK/Canada pilots are documented as planned, not live.

Changelog closeout: Record adapter design and first non-FR pilot boundary.

SAAS-0036

done

Ship the first generated Python partner SDK beta

Audit, QA, data and internal automation teams will want a supported Python path once the Node/server integration lane is proven.

Phase

Later

Priority

P2

Owner

/rook-410

Depends on

SAAS-0032, SAAS-0033, SAAS-0035

Acceptance criteria

• A generated Python beta client exists with packaging metadata and no handwritten business-logic divergence from the bounded REST/GraphQL/MCP contracts.
• Python examples cover search, retrieve, review-preview, export bundle preview and MCP tool calls with tenant/workspace/cost-unit headers.
• Contract tests prove the Python client matches the static OpenAPI and partner contract artifacts and keep rotor/control-plane helpers out of scope.
• Public docs keep Python as the second SDK target, still server-side only, with Scenario, answer-ready, client-reliance, semantic-search and professional-certification flags false.

Changelog closeout: Record generated Python SDK beta package, examples, contract-test receipt and public docs update.

SAAS-0037

done

Publish a single partner integration-pack handoff

Reviewers should be able to fetch one explicit pack rather than infer the bounded integration surface from several scattered assets.

Phase

Later

Priority

P2

Owner

/rook-410

Depends on

SAAS-0033, SAAS-0034, SAAS-0035, SAAS-0036

Acceptance criteria

• A single public integration-pack asset exists and links the OpenAPI snapshot, partner contract, quickstart and SaaS roadmap.
• The public API guide links the pack explicitly for acquirer/reviewer use.
• CLI docs mention the pack as the canonical diligence handoff for bounded integration surfaces.
• The pack keeps SDK beta status repo-only and preserves Scenario, answer-ready, client-reliance, semantic-search and professional-certification false boundaries.

Changelog closeout: Record the public partner integration-pack asset, API-page wiring and CLI-doc mention.

SAAS-0041

done

Make draft dossiers and exports first-class outputs of the review runtime

For buyers and professional users, the durable object is the dossier or export bundle they can reopen, review, defend and pass downstream.

Phase

Later

Priority

P2

Owner

/rook-410

Depends on

SAAS-0028, SAAS-0038, SAAS-0039, SAAS-0040

Acceptance criteria

• The review runtime can create or update a draft dossier with revision id, audit id, corpus/index snapshots, source refs and review_status=draft.
• Exports remain tenant/workspace scoped, buyer-brandable, retryable and auditable through the existing export-bundle contract rather than a parallel artifact path.
• A reviewer can reopen a bounded dossier/export preview without losing its snapshot-pinned evidence lineage.
• The feature remains draft/review-gated and does not imply answer-ready, Scenario-ready, human-reviewed, client-reliable or professionally certified output.

Changelog closeout: Record dossier/export runtime wiring, revisioned fixtures, reopen proof and the preserved draft-only boundary.

SAAS-0042

ready

Expose source-change impact against saved dossiers and workspaces

The corpus factory becomes a product moat when source changes can trigger bounded impact signals over prior draft work instead of only refreshing the index silently.

Phase

Later

Priority

P2

Owner

unclaimed

Depends on

SAAS-0029, SAAS-0041

Acceptance criteria

• A changed source can be linked to affected draft dossier/workspace/export ids with severity and recommended next action.
• Impact analysis uses source freshness/supersession evidence and does not require semantic-search activation or Scenario unlock.
• Public docs and status surfaces explain this as bounded change intelligence over draft/review artifacts, not as automatic legal/accounting sign-off.
• All protected readiness/professional flags remain false unless a separate launch gate proves otherwise.

Changelog closeout: Record the change-impact contract, affected-dossier fixture, and the first bounded status/docs wiring.

SAAS-0045

done

Publish a buyer-facing architecture risk register and mitigation map

Diligence reviewers are now reading the architecture as an acquisition artifact, so the open risks should be explicit, bounded and paired with active mitigations instead of being scattered across reviews and notes.

Phase

Later

Priority

P2

Owner

/rook-410

Depends on

SAAS-0020, SAAS-0021, SAAS-0043, SAAS-0044

Acceptance criteria

• A buyer-facing risk register exists with current risk, mitigation status, linked SAAS tasks and explicit hard boundaries.
• The register includes host/substrate coupling, tenant/auth maturity, source-rights diligence, Scenario locked state, semantic-search planned state and professional-review/client-reliance boundaries.
• The register is linked from the architecture or diligence pack and stays consistent with the public roadmap and changelog.
• The document does not overclaim legal clearance, customer traction, Scenario launch, answer-ready status or professional certification.

Changelog closeout: Record the risk register path, public linkage and the roadmap tasks it references.

SAAS-0055

ready

Define the credentialed sandbox promotion gate

Moving from fixture stubs to live third-party sandbox calls should be deliberate, auditable and reversible, especially for accounting and cabinet workflows.

Phase

Later

Priority

P2

Owner

unclaimed

Depends on

SAAS-0020, SAAS-0025, SAAS-0052, SAAS-0053

Acceptance criteria

• A credentialed sandbox gate document exists with required security, auth, test and rollback evidence.
• The gate requires scoped secrets, no browser/mobile tokens, audit IDs, tenant/workspace isolation and no protected rotor mutation.
• The gate requires dry-run fixture parity before any live third-party sandbox call.
• The gate explicitly blocks production/customer data use until a separate legal/security/product approval path exists.

Changelog closeout: Record the sandbox promotion gate, security requirements and live-call approval boundary.