Aevum Track A — Corrected TestFlight Execution PM Plan

Date: 2026-04-18

Prepared by: Codex acting as PM / technical control layer

Scope: Stabilize the current iPhone core for internal TestFlight readiness

Baseline class: Phase 0 iOS local intelligence prototype

Source basis: Repository-ground-truth review, not vision-only intent

1. Objective

Stabilize the current Aevum iPhone product into a bounded, truthfully presented, internally testable TestFlight build without widening scope into iPad parity, Mac, full external integrations, or a new platform architecture.

2. Control Statement

This plan supersedes the earlier Track A draft where that draft conflicts with current source reality.

The technical team should treat this document as the operative execution brief until replaced by a newer PM-issued revision.

3. Ground Truth Corrections

The following statements are now confirmed from the current codebase:

1. IntelligencePipeline.shared.boot(with:) is already called from the main app flow in MainAppView.onAppear.
2. PhiSandboxView no longer owns the primary pipeline boot path; it has already been marked deprecated for that responsibility.
3. The remaining risk is not “pipeline boot missing everywhere.” The risk is that bootstrap is not hardened or proven idempotent across repeated view appearances and non-UI entry points.
4. LogThoughtIntent still relies on the pipeline directly, so Shortcut/AppIntent safety is not fully solved by the current UI boot path alone.
5. Dashboard capture is intentionally different from queue-first capture flows and should not be refactored casually without first defining the canonical write contract.
6. Integration-facing UI and language still overstate maturity relative to current implementation.

4. Track A Release Boundary

In Scope

• iPhone app stabilization
• app launch and unlock reliability
• capture reliability
• pipeline and local persistence safety
• truthful labeling of prototype integrations and stubs
• internal TestFlight operational readiness

Out Of Scope

• separate iPad productization
• macOS product
• full REST CRUD API redesign
• true Notion / Google / Outlook production sync
• complete automation platform
• investor narrative expansion beyond code-grounded capability mapping

5. Execution Principles

1. Stabilize reality before expanding scope.
2. Prefer hardening existing paths over introducing new architecture.
3. Do not merge conceptual parity and actual parity.
4. Any user-facing surface that implies a capability must either work, be bounded, or be labeled.
5. Every release claim must map to a verifiable code path.

6. Exact Revised Tasks

Task A1 — Harden Bootstrap Into A Single Safe Startup Contract

Problem

Bootstrap is currently triggered from MainAppView.onAppear, which may run more than once. Local API startup and pipeline boot both need deterministic repeated-launch behaviour.

Required work

• Define a single bootstrap contract for local startup
• Make pipeline boot idempotent or explicitly guarded
• Make local API listener startup idempotent or explicitly guarded
• Ensure repeated foreground / tab / unlock transitions do not create unsafe duplicate startup behaviour

Acceptance criteria

• Repeated appearances of the main app surface do not create duplicate pipeline startup side effects
• Repeated appearances of the main app surface do not create duplicate local API listener side effects
• Cold launch and warm relaunch both preserve local capture behaviour

Task A2 — Add Non-UI Bootstrap Safety For Intents And Background Entry

Problem

Shortcut/AppIntent flows can touch the pipeline without guarantee that the interactive main UI path has booted first.

Required work

• Define how AppIntents safely access the pipeline when the app is not already fully active in the main UI path
• Ensure LogThoughtIntent either triggers safe bootstrap or routes through a guaranteed initialized execution path
• Validate launch-into-dictation and direct-thought logging separately

Acceptance criteria

• StartDictationIntent works from a cold state into the expected app capture flow
• LogThoughtIntent does not fail solely because the main interactive UI was never opened first
• No silent data loss occurs in background or cold-start intent execution

Task A3 — Define And Freeze The Canonical Write Contract

Problem

There are multiple ingestion/write patterns:

• Dashboard -> BehaviourIntelligenceLayer -> InstantProcessor -> local persistence
• Capture/import/habit/legacy -> IntelligencePipeline
• system and derived outputs -> pipeline

This is not automatically wrong, but it is currently undocumented and therefore unstable.

Required work

• Write a short engineering rule defining which flows are direct local writes, which are queued, and why
• Preserve low-latency Dashboard behaviour unless a consciously approved redesign replaces it
• Explicitly document which outputs are user-originated, system-derived, imported, or background-enriched

Acceptance criteria

• Team can answer “where does this flow write first?” for every capture surface
• No new capture path is added without being assigned to the canonical write contract
• Test cases cover each write class

Task A4 — Truthfully Bound Or Hide Prototype Integrations

Problem

Some current UI and interaction surfaces imply more mature external integration than the source actually supports.

Required work

• Label prototype / mock / alpha-stub surfaces clearly
• Remove or hide unsupported user promises where necessary
• Reconcile integration language across settings, widget/timeline surfaces, and Siri-like conversation entry points

Acceptance criteria

• No user-facing surface implies real external sync if the implementation is mock, placeholder, or native-only
• Settings and related surfaces use consistent maturity labeling
• Siri / conversational shortcut stubs are either hidden or clearly bounded

Task A5 — Reconcile Integration Drift In Source

Problem

Some source surfaces and integration managers are no longer aligned cleanly at the contract level.

Required work

• Reconcile calendar integration UI assumptions with the current CalendarIntegrationManager
• Remove dead or misleading capability references
• Align tests with actual source interfaces

Acceptance criteria

• Build surfaces, tests, and integration models agree on the same current contract
• No obsolete auth-state assumptions remain exposed in release-critical flows

Task A6 — Stabilize Scheduled Processing Claims

Problem

Daily/background processing code exists, but scheduled execution claims are stronger than proven runtime evidence.

Required work

• Confirm whether scheduled processing is part of the release baseline
• If yes, fully verify task registration, scheduling, and expected behaviour
• If no, suppress or downscope any UI or documentation that suggests active scheduled intelligence

Acceptance criteria

• Scheduled processing is either verified or explicitly not claimed
• Release notes and UI reflect the truth

Task A7 — Build A Release Truth Matrix

Problem

The product needs one release-controlled list of what is shippable, what is internal-only, and what is prototype-only.

Required work

• Create a release truth matrix across all major surfaces
• Assign each feature one of: ship, internal, prototype, hidden
• Use this matrix to control TestFlight presentation

Acceptance criteria

• Every visible surface has a release status
• PM, engineering, and QA are using the same matrix

Task A8 — Execute Manual And Technical Readiness Validation

Problem

The current system is not yet validated end-to-end at the app lifecycle level.

Required work

• Build a simple release verification matrix
• Run targeted app lifecycle checks
• Record failures against specific flows, not generic “app unstable” labels

Acceptance criteria

• Each critical journey has a pass/fail outcome
• Known blockers are enumerated with severity and owner
• TestFlight go/no-go can be decided from evidence

7. Acceptance Criteria By Release Theme

Launch & Unlock

• App launches cleanly after install
• App launches cleanly after onboarding completion
• App launches cleanly with biometrics enabled
• Unlock flow does not break subsequent capture flows

Capture

• Dashboard typed capture persists without loss
• Dashboard voice capture persists without loss
• Capture Sheet text capture persists without loss
• Capture Sheet voice capture persists without loss
• Import / habit / legacy paths either work or are explicitly scoped out of release

Pipeline

• Queue-backed flows process after enqueue
• No duplicate or unstable bootstrap behaviour is observed during repeated use
• Pipeline-backed surfaces do not depend on hidden sandbox-only behaviour

Integrations & Stubs

• No visible surface overclaims full external integration
• Any remaining prototype surface is clearly labeled

API

• Local API starts without destabilizing the app
• Local API remains correctly framed as a narrow inference gateway, not the app’s CRUD system

8. Test Matrix

9. Go / No-Go Gates For Internal TestFlight

Go Only If

• bootstrap is stable across repeated app lifecycle transitions
• at least one typed and one voice capture path are demonstrably reliable
• shortcut flows do not silently drop data
• user-facing integration claims are truthful
• no blocker-severity launch or persistence issue remains open

No-Go If

• pipeline or API startup is non-deterministic
• capture succeeds only in some surfaces but fails silently in others
• release UI implies real external sync that does not exist
• app lifecycle transitions can regress persistence or capture reliability
• TestFlight would require users to infer which features are real

10. Roles And Reporting Model

PM / Control Layer

• maintain scope boundary
• maintain truth matrix
• approve release claim language
• block scope creep during stabilization

Technical Team

• implement tasks against this plan
• update source files
• provide proof of acceptance criteria
• avoid architecture expansion unless approved

QA / Validation

• validate against the test matrix
• report pass/fail against specific scenarios
• separate regression from known prototype limitation

11. Required Team Deliverables

The technical team should update and maintain:

1. release truth matrix
2. bootstrap architecture note
3. capture contract note
4. blocker register
5. TestFlight readiness checklist

12. Recommended Working Rhythm

1. Stabilize bootstrap
2. validate AppIntent safety
3. freeze capture contract
4. hide/label stubs
5. run lifecycle matrix
6. decide TestFlight go/no-go

13. PM Decision Log

Decision 1

Track A is iPhone-core stabilization only.

Decision 2

No external integration maturity may be implied beyond current reality.

Decision 3

Canonical write behaviour must be documented before any ingestion refactor.

Decision 4

Any deviation from the Aevum tooling and execution policy requires explicit user approval.

14. Current Recommendation

Proceed with Track A, but only under this corrected plan.

Do not let the team spend effort “moving pipeline boot to root” as if that work were still undone. The real work is hardening startup safety, protecting non-UI entry points, freezing write semantics, and making the release honest.