Eve task board and monorepo backlog rationalization

Date: 19 September 2026. Audited code: e6a64111e3abb96af5a89d194d5c2c8c2d023724. Status: proposal for review; no implementation or task-state changes authorized by this report.

The recommended direction is to complete a few usable, governed vertical slices on the architecture already present, with one implementation owner per capability. Preserve the owner's presentation-first priority, but repair the board's dependency semantics before trusting its readiness claims. Consolidate acceptance checklists around those slices, separate release and external proof from build work, and stop counting historical plans as additional implementations.

The September 18 audit and its subsequent rewrites improved the backlog substantially. They did not establish that every rewritten task is still necessary. This pass found already-implemented safety-service work, missing cross-family dependencies, requirements hidden outside the board, and runtime deployment gaps in the newest presentation plan.

1. Scope, method, and what the numbers mean#

The audit inventories every current board row, every tracked checkbox-bearing Markdown file, the committed document catalog, and comment-like code debt markers. Recommendations cover every open item through a logical group. Source review followed the owners, entrypoints, contracts and infrastructure relevant to those groups, with focused tests where they could disprove a task premise. It is not a claim to have manually verified every implementation behind 24,822 checkboxes or rerun the monorepo's complete test portfolio.

The evidence bundle includes:

• Exact measurements.
• Every open task's proposed home and disposition: 24,822 keys, each mapped exactly once, preserving source path, line, current state and blocker.
• Every checkbox file: 1,411 files, with classification, counts and content hash, including all 75 files with open implementation-tracker items.
• Document catalog: source documents indexed separately from generated slide and Docs Center entries. Catalog inclusion is discovery coverage, not proof that every paragraph is an adopted requirement.
• Inline debt markers and repeated wording.
• A read-only inventory and accounting checker.

There are 51 registry families and 38 database families. The other families classify proposals, inventories and reference material. The database has 34 retained terminal rows; these are not a count of all completed work, since most historical checked items were never imported as task rows.

Outside the execution board are 8,845 unchecked proposal boxes, 26,648 unchecked inventory boxes, and 2,040 unchecked template/reference boxes. Do not add these to the implementation backlog. Some are duplicates; some are operating checklists; some require a fresh adoption decision. The current document catalog contains 16,379 entries, including generated presentation and reader entries. The Markdown inventory contains 11,472 files before this report.

The source-marker scan found 152 comment-like TODO, FIXME, HACK or XXX matches in 84 files under apps, libraries, services and tooling. Many are quoted fixtures, generator scaffolds or references to task IDs. The bundle labels them as such; 152 is not a defect count or an exhaustive count of incomplete code.

2. Current architecture and the coherent path forward#

The Telegram bot and Mini App are also explicitly in V1.0 scope in V1/TELEGRAM_SURFACE_PLAN_2026-08-05.md; they are not deferred with native mobile. Preserve the chosen BFF transport and channel-specific acceptance.

For UI, the required frontend skill supports a primary working surface, navigation and secondary context. Apply that to decks, notes, generation and workbenches. Do not turn every repeated contract cell into another panel, dashboard or independent screen. Keep all required keyboard, accessibility, responsive, state and error behavior as acceptance criteria.

3. Findings that change the execution plan#

F01. The scheduler's graph is materially less complete than the plans#

The database contains 7,700 edges: 7,340 parent/child roll-ups and only 360 explicit prerequisites. Zero edges cross family boundaries. This does not mean the products are independent.

tools/eve-task-board/lib/deps.mjs resolves IDs inside their family and parses selected dependency phrases. It does not encode the Isis tracker's section-level Dependencies: blocks as execution edges. The presentation plan references earlier EI items in prose without machine-readable prerequisites. All 52 ready EI items have zero recorded dependency edges, including apply, regeneration, live demonstrations and artifact generation. All 1,115 ready redesign items pass the dependency predicate; Isis has 225 eligible items out of 226 ready. These are availability calculations, not sensible simultaneous starting points.

Concrete missing relationships include:

• EI.7.03 after its persistence/service work; EI.9.02 after the draft, runner, approval, apply and receipt contracts; final live demonstrations after the behaviors they demonstrate.
• Isis T.02/T.05 after the relevant model admission; F.20 after the film pilot's actual producers; workbenches I6–I9 after I0.20's crosswalk.
• Human-video 182.C.40.01 after consented references and externally fetchable object storage. Its own body says these block the real run, yet it is ready.
• Ambient-rail consumers after the simulations they require; presentation chapters after the capabilities they describe; shared label validation after one human-labeled corpus.

Recommendation: explicit fully-qualified prerequisite keys, section gates expanded into leaf prerequisites, edge provenance, and a readiness check that blocks unresolved execution dependencies. Do not infer dependencies from every casual citation. Preserve parent roll-ups separately from prerequisites.

F02. A passing board check does not establish schedulability#

./eve check --json returns no problems and ./eve drift --json returns empty edited/checked/unknown lists. Nonetheless, task_links contains eight unresolved-dep entries:

check.mjs detects cycles among present task rows, but does not report these unresolved links. Additionally, 56 ready items contain a [later] label in their body; the label does not make the database defer them. Some labels may themselves be obsolete. Decide the release/priority once, then make prose and machine state agree.

Recommendation: distinguish open, unblocked, leased, awaiting external proof and acceptance-only work in reporting. Reconcile prose scheduling labels and terminal-family residue. The closed eve-task-board family still contains parked ETB.9.01; expose that remaining live-eval obligation explicitly.

F03. Task identity and multiple sources of state need a stronger contract#

14,335 open rows have no external task ID. Their keys depend on text and headings. The importer already has a three-step identity-reconciliation ladder; this audit does not propose rebuilding it. Substantial rewrites or moves can still change identity without an exact match. Preserve aliases, journals, evidence and old source anchors when adopting the canonical plan.

pull.mjs mirrors workbench state without checking the tracker box, while import.mjs derives state from the tracker and specially preserves terminal state only for procedure-policy families. Audit and test the full promote → lease → pull → import → done sequence, including rejection, verification and lost leases. The separate-command tests do not establish the combined lifecycle. This is a source-indicated integration risk, not a claim that this session observed a live task being lost.

The generated TODOS/BOARD.md also says context, docs search, merge resolution, promote and pull are not built; their implementations and tests exist. Its fallback merge guidance can discard journals. Generate current help from the implemented command registry and teach the installed row-level merge driver.

F04. Safety automation was rewritten from stale defect descriptions#

Fresh result: all 156 tests in five service test files pass. This overturns the task text's reliance on old failing-test counts. It does not certify the service for production.

Source anchors: apps/lilith/svc-safety-automation/src/app.ts:53,117,312,334,1601,1979,2021,2053; __tests__/safety-automation.test.ts; __tests__/health.test.ts also contains permissive “200 or 400” assertions. This is a good candidate for one small service-hardening workstream, not eight assumed-new implementations.

F05. Presentation integration needs a deployed write path and narrower milestones#

EI.1–EI.3's landed host/message/citation behavior should be retained. The final snapshot includes EI.3.06's canonical navigation entry/contextual slide action and EI.3.07's responsive layout, F6 focus transfer and browser verification; do not recreate them. EI.3.07 also fixed a server/client boundary error that component-only tests had missed. Its mobile result explicitly retains the copilot's minimum viewport of 1024 px: keep phone deck access, but do not promise a phone copilot without a separate product/accessibility decision. The upstream completion notes also record an unrelated remaining admin interruption-capability test failure, which belongs in C02's baseline rather than a false claim of a completely green admin suite. The remaining EI.4–EI.6 context, grounding, trust-label and operator-admission work is valid. The large remainder should be separated into read, notes, controlled authoring, and ad hoc artifact milestones rather than one undifferentiated Phase 0.

The write proposal assumes BFF can run Python against a writable checkout while admin serves the resulting preview and published files. The checked-in BFF container does not package that Python/rendering environment; admin's published directory is a read-only mount. Local co-location does not solve container visibility, worker permissions, locking across processes, interruption recovery, receipt/file consistency or atomic publication. EI.1.06 packages published output; it does not deliver this authoring runtime.

Recommended design: BFF authorizes and records intent, a bounded isolated worker owns a proposal checkout and rendering tools, and admin reads versioned artifacts. Reuse the workbench's execution/lease machinery where it fits; do not grant the general BFF unrestricted write access to the shared checkout. Text edits may remain lightweight jobs, but still need one durable lifecycle and an explicit deployment contract. Stage before publication; use revision hashes for both apply and revert; test crashes between file writes, receipt writes and publish.

EI.0.03's parked threat-model task should split into an early design/gap record and later verification of actual controls. The threat model should identify the missing runtime boundary before it is built; it should not claim nonexistent controls as implemented.

EI.12's ad hoc decks overlap Eve 8.15's artifact workspace and 17.23's generated media delivery. Share artifact identity, tenant/owner checks, revisions, retention/erasure, attachments and approval receipts; keep deck rendering and slide-specific behavior as a format adapter. Similarly reuse ETB.8.10's committed source corpus work when extending document grounding rather than adding a third independent Docs Center ingestion path.

F06. Creative ownership remains unresolved at the implementation boundary#

Workbenches I0.20 and Isis T.21.07 are legitimate reconciliation work. They should produce one acceptance crosswalk used by Eve Phase 5, workbenches I/B, Isis T/F, Neith 144.2.7 and relevant phase-71/78 residue. Shared operations can have both interactive and headless transports without duplicating job, asset or policy authority.

T.00.06 asks for the ADR's “nine” questions, specifically Q1–Q9. ADR-0008-open-3d-studio-capability-ownership.md §8 has eleven, including Q10's two workflow registries and Q11's release qualification. Its acceptance clause requires every question answered, so the task is internally incomplete. Expand it to all eleven, preserve the already-recorded delegation and decisions, and link each answer to an implementation or a deliberate non-goal.

Do not repeat yesterday's obsolete claim that Eve 15.7/17.4/17.22 have no reconciliation with Isis: their appended September 18 notes now establish it. The old leading text still names superseded provider owners. Because this tracker has an append-only policy, expose an explicit effective requirement in the canonical crosswalk; alter the original text only through its digest/evidence procedure. Provider-specific implementation should be a choice behind a capability, not a permanent product promise.

F07. Scope inflation obscures the smallest useful deliverables#

The workbench ledger holds 8,451 open cells. Its 727 UX/STD/CAP contract cells are requirements and acceptance, not 727 independent builds. Phase Y has 1,370 open cells, V 1,465, E 1,444, A 1,012 and B 1,029. They are now deferred, which is correct; enumerating thousands of behaviors is still not decomposition into verified increments.

For each domain, first reconcile existing routes, contracts and providers, then choose a single usable author → validate → persist → review → publish path. Attach the relevant contract cells to that path. Split an implementation only when it has a distinct owner, failure boundary or independently testable output. Do not create a universal workflow framework before two consumers demonstrate a shared need. Do not discard these requirements just to reduce counts.

The redesign ledger similarly contains 1,386 open Phase D entries. The repetition screen finds 78 groups containing 820 occurrences across tracker files, mostly chapter procedures. This is a first-line lexical screen, not a count of semantic duplicates. A chapter brief, narration, responsive screenshots, PDF check and receipt can become one parameterized delivery checklist per chapter with independent per-slide evidence. Fifty copies of the procedure need not be fifty different engineering projects.

F08. Release, host and external-proof gates are mixed with ordinary work#

Keep V1.0 correctness separate from V1.1 mobile/fiat and V1.2 Metis/Veritas. The operator workbench priority is an owner choice, not proof that those rooms are released. Coverage of a deferred route's refusal remains useful; a full feature journey into that room waits for its release.

Phase 182 has seven ready items despite some requiring a consented corpus or publicly fetchable reference assets. Separate packaging and fixture-driven contract tests from real likeness, fairness, performance and release evidence. Use the existing Isis infrastructure contract for delivery, and add the human-video-specific consent and wipe constraints; do not create another GPU control plane.

OYA.G1 loads an admitted model from G2, while G2 asks to measure through G1. This is a sequencing knot in the prose even though no graph edge records it. Split G2 into static license/hash admission, G1 into the bounded runtime using one admitted fixture, and then G2's measured performance admission. Apply the same “contract → implement → measure → promote” distinction to GPU and training tasks elsewhere.

Hardware-specific captures, full-duration soaks, signing and human review remain real acceptance work. A software Vulkan pass proves functional behavior, not physical-device frame time. A hosted Windows browser test does not prove interactive UAC, GPU capture or certificate-backed distribution. Installable tools are setup steps; account rights, physical devices and people remain explicitly owned dependencies.

F09. Non-board plans contain both useful intent and stale prescriptions#

The broad reference-docs family includes implementation/migration notes, Psyche security and code-quality audits, Nyx's caching strategy and Yemaya's known limitations. Classification as a reference is not evidence their findings were resolved. Reconcile these documents by source path and current caller; promote surviving defects with a canonical ID. Do not blindly adopt January security prescriptions or numerical targets without checking the live design.

Two concrete inline gaps survive source inspection:

• apps/psyche/api-gateway/src/api_gateway/routers/health.py:129 returns healthy database/Redis checks without connecting to either. The router is mounted by api_gateway/app.py:188. Add dependency-aware readiness and tests for unavailable/unconfigured dependencies; retain liveness separately.
• apps/aphrodite/streaming/src/routes/metrics.ts returns constant zero metrics and empty diagnostic results; /metrics is mounted in src/app.ts:228. Wire actual bounded telemetry or expose unavailable measurements explicitly. Do not count absent measurement as zero traffic/errors.

The notification test's rate-limiting TODO is a test-determinism follow-up. Most Iris/Neith marker hits are generated examples or parser fixtures; preserve those examples instead of “fixing” their intended placeholder strings.

F10. Historical plans and actual product acceptance need separate retirement rules#

Phase snapshots, the Neith combined proposal and its parts, P2 target inventories and the Antigravity plan are already classified outside live work. Preserve their provenance and link to current owners; do not resurrect them as a second backlog. The Sophia convergence proposal names moved service paths and should be superseded by a current ownership inventory if further convergence is wanted.

The two older AGENTIC_CONTENT_* trackers still hold 25 open items. Some remain useful, including generation integration, engine import and calibrated quality. Move only their unique residue into the current Isis/content/evaluation owners, then retire the competing ledger authority. A completed function in an older tracker is not proof that an end-to-end generation lane exists today.

Other proposal-scale plans need explicit treatment as well:

The V1–V9 ledger and phase 180 intentionally use pinned procedures. Their new re-audit/Windows-attempt trackers are evidence-producing feeders, not replacement sources of completion. A retirement or consolidation must update the ledger, manifest and synchronized documents together. The previous audit demonstrated that cosmetic checkbox rewrites can break real release gates.

4. Disposition of every implementation family#

Counts are open entries, including blocked and deferred items. C-numbers refer to the canonical execution groups in §6. The machine crosswalk supplies every individual key; the tables below supply the reasoning for the groups.

The workbench totals also include 126 cross-domain integration cells and 115 rollout/final-definition cells. Keep them as explicit cross-consumer acceptance, not an excuse to defer integration tests until every domain is complete.

Other phase files: complete logical-group disposition#

All 36 open files in the generic phases family are covered here. Source lines, IDs and current blockers remain in the crosswalk.

V-series residue and audit-remediation files#

Coverage and gates: all eleven families#

5. Retirements, consolidations and preserved alternatives#

“Retire” means remove duplicate execution authority while retaining a source link and disposition. It never means checking an unimplemented task as done. The following changes are recommendations for adoption, not edits made here.

Do not retire human calibration, consent, licensed data, recovery, mobile/device, signing or release obligations merely because an agent cannot complete them in one session. Keep alternatives such as a future paid DCC, model lane or research training run as options with triggers, not permanently ready tasks.

6. Proposed canonical execution backlog#

These are bounded execution groups with explicit acceptance and predecessors. The TSV maps existing leaf tasks into them; it does not replace their unique requirements with a vague epic or authorize bulk closure. Before a group is claimed, its next leaf deliverable must name an existing owner/path, observable result, relevant acceptance set and required environment. Parent and acceptance rows close from evidence, not from an arbitrary percentage of child checkboxes.

Waves express priority, not a requirement to finish every group before starting the next wave. A dependency on a named contract or producer means that specific leaf deliverable, not its owner's entire portfolio. In particular, define the C13 artifact contract alongside C05 so C06 need not wait for all retrieval, channels or creative tooling. Capability-specific C12 admission travels with the capability it guards.

Wave 0 — trustworthy scheduling and a limited verification baseline#

Wave 1 — finish the first-priority presentation experience#

C03 is the next product milestone. C01 should be a small enabling repair, not an excuse for another board rewrite. Do not require all presentation chapters to finish before the next product lane can make useful progress.

Wave 2 — a single creative capability path#

Wave 3 — governed Eve and current-release correctness#

These groups may proceed independently where their own dependencies are met. Do not make a licensed After Effects path block text retrieval, and do not use text-only success to admit the After Effects path. If the safety service or false-ready endpoint is exposed, its remediation precedes expansion of that exposure; this is a concrete service defect, not a reason to stop unrelated read-only work.

Wave 4 — grounded domain and product increments#

C19 and C20 are portfolio containers for separate product milestones, not one multi-domain implementation task. Their inherited leaf IDs remain addressable. After the common prerequisites, pick the next domain or product by the current owner priority and readiness; do not assign speculative dates or manufacture a total order between independent products.

Ongoing evidence and release work#

7. Important missing or incomplete tasks to add on adoption#

These are proposed additions or explicit residuals, not newly inserted board rows.

1. C01 prerequisite conformance: cross-family references, section/range prerequisites, unresolved IDs, later-label reconciliation and stale blocker detection, with real examples from Isis/EI/P14.b/phase 182.
2. C01 lifecycle conformance: import/pull/claim/verify/merge round trips, stable aliases for rewritten tasks, and clear visibility of unfinished work in a closed family. Do not assume isolated command tests cover the workflow.
3. C02 evidence consumers: an acceptance manifest mapping changed tracker families to their pinned-text/schema/generator/release checks. Preserve the existing append/procedure policies and make missing setup visible.
4. C05 deployment qualification: renderer image/toolchain, isolated checkout, shared artifact visibility, worker identity, atomic publish, bounded storage, cancellation and crash recovery across file and database state.
5. C06/C13 shared artifact contract: align decks and other generated artifacts on identity, revisions, ownership, erasure and receipts before implementing separate saved/recent stores.
6. C08 ADR completeness: add Q10/Q11 and a consumer-aware retirement list. Consolidate workflow catalog/capability states rather than adding a third registry.
7. C15 safety-service negative and durable-path coverage: replace permissive success assertions with contract assertions; require actual persistence and authorization. The current passing suite leaves both gaps.
8. C16 truthful health and metrics: the two mounted source gaps above, coordinated with existing observability tasks and actual deployment reachability.
9. C18/C19 requirements traceability: map contract/acceptance cells to concrete domain increments, including the V1.0 rooms absent from the large workbench authoring ledger when those rooms actually require authoring work.
10. C22 staged admission: break Oya's admission/runtime/measurement knot; apply the same explicit ordering to media/ML worker profiles.
11. C27 hidden-plan adjudication and language policy: review the reference catch-all, retain current findings, and reconcile the Rust recommendation with active contributor instructions before initiating a migration.
12. C28 external-input register: reuse existing owner-action records for label sheets, regional model routing, Telegram credentials, selected store binary, licenses/corpora, signing and staging access. Record prerequisite, owner and expiry; do not ask again for choices already recorded.

8. Adoption, verification and limitations#

Adoption should be a separate change after review:

1. Accept or amend the architecture boundaries and ordered groups above.
2. Add stable canonical/alias fields and explicit edges before relocating or rewriting source tasks. Preserve all evidence and current blockers.
3. Apply source-specific policies: ordinary trackers through Eve; append-only and procedure trackers through their declared evidence/digest workflows.
4. Reconcile duplicate requirements item by item, retaining unmatched acceptance. Retire with a reason and replacement link, never a false completion checkbox.
5. Regenerate dependent catalogs/manifests, import then regenerate the board, and verify the small next-work queue actually respects the adopted graph.
6. Execute the first scoped product slice; reassess the next batch from its evidence.

Fresh verification during this audit:

No task was claimed, completed, parked, unparked, rejected or promoted. No application implementation, tracker, registry or committed board database was changed. This deliverable consists only of the report and its audit evidence. No paid generation, live production changes, external messages or credential access were needed.

The host has approximately 15 GiB RAM with swap and another agent process was active. Verification therefore stayed targeted and sequential. No full Nx, Next production, native packaging, GPU, broad Playwright or mobile matrix was run. This report does not claim those products are green. The prior audit's known unrelated V2/V6, inventory and charter-generation failures were not rerun or relabeled as fixed. They belong in C02's owner-specific baseline.

The review decision is whether to adopt this canonical organization and its boundaries. Hardware access, paid spend, human labels and release decisions remain separate prerequisites, not implied approvals to execute them.