ProjectOS: proving the workflow before real-world use

Status: In progress. R2 received scoped Architect and Product Owner acceptance. R3 remains under review; this record describes a synthetic validation effort, not an installation or release.

The problem is keeping work coherent

ProjectOS is intended for an individual coordinating mixed personal and professional projects. Its job is to turn an outcome into a bounded project, milestones, and actionable work; make prerequisites and simultaneous work visible; and preserve an inspectable record as plans change. The underlying motivation is familiar: priorities compete, unrelated work expands, and it becomes harder to tell what matters next or what is safe to start.

Those are design goals, not measured productivity results. Before relying on the system for actual work, the readiness review asked a more basic question: do the project, its tasks and relationships, its dates, and its history continue to tell the same story through ordinary use, edits, and recovery?

ProjectOS keeps canonical records in human-readable Markdown for a local vault workflow. SQLite is a rebuildable query projection: it helps retrieve and display the records, while Markdown remains authoritative. Revision checks help protect edits when state has changed elsewhere. This architecture makes recovery and record integrity part of the user experience, not only an internal implementation concern.

1. Accepted baselineR2October 8, 2026 · scoped acceptance
2. Current reviewR3In progress · acceptance gates remain open

R2 made the everyday workflow more coherent

R2 addressed the parts a person encounters while planning and finishing work: typed Task and Subtask forms, completion controls, work-in-progress feedback, affected-view refresh, comment display, date-only export behavior, and recovery when a save response is uncertain. The candidate received scoped Architect and Product Owner acceptance on October 8, 2026. That acceptance covered reviewed professional and personal journeys and disposable-state recovery; alternate-browser-timezone GUI behavior and some CI evidence remained outside the demonstrated scope.

R2’s acceptance established a useful baseline for the next question. Would the records and relationships remain trustworthy when the repository changed under load, a derived view needed rebuilding, or the desktop package had to recover?

R3 tests the system around those workflows

R3 focuses on performance, write contention and freshness, recovery, existing Habit behavior, and Windows lifecycle and packaging. One accepted repository optimization reduced repeated filesystem path work while retaining link checks, strict path resolution, and containment safeguards. Cache handling was also tightened so mutable entity data stays isolated between callers. Other reviewed changes make projection observation ordering, fallback behavior, and watcher status more explicit while preserving Markdown as the source of truth.

The Architect independently ran 47 repository read and write integration tests covering junction rejection, traversal and path mismatch, cache isolation, and revision and staging behavior. All 47 passed on that reviewed source. This supports the specific repository-safety change, not acceptance of the whole product.

The package was exercised with complete synthetic work journeys

On an isolated synthetic vault, the exact portable candidate completed one professional and one personal project journey, including their explicit closure actions. The personal journey exercised both supported child shapes: a true Subtask and a historical Task with a parent relationship. Independent inspection corroborated the completed projects, committed create receipts, and stored relationships. The Task selector also reached rows 251–300, saved a related Task, and displayed the relationship on readback. The existing Habits interface recorded a numeric completion and a Skip. These capabilities were exercised as part of the review; this continuation did not introduce a new Habit Tracker or establish every workflow as complete.

The wizard’s date fields required focused keyboard input for the values to reach application state. After correcting the test input method, both project journeys completed; no product defect was confirmed from the discarded automation attempt.

A comparison against the same isolated synthetic vault’s baseline found 1,243 Markdown records unchanged, no changed or removed records, and 16 intended additions; one ephemeral writer lock disappeared. This describes that scenario only. It does not establish universal data preservation or describe a live vault.

The performance result sets a clear next constraint

With 1,212 starting synthetic entities, the worker measured 100 creates and 100 updates with the watcher disabled. The server/service p95 was 4.602 seconds for create and 6.493 seconds for update, against the 2-second routine-write objective. This measures the server/service path, not the full request-to-visible interface journey; both results still fail the stated target.

Create

4.602 s2 s target · over

Update

6.493 s2 s target · over

The Architect accepted the code change as a bounded optimization, but the performance gate remains open and its target was not waived. Earlier comparison samples used different corpus conditions, so they do not establish a controlled speedup from this change. An alternative that would acknowledge a save before all processing had finished was deferred: its estimated latency still missed the objective, while it would make recovery and confirmation more complex.

The benchmark makes the tradeoff legible: preserve truthful write confirmation and improve the measured path, rather than changing what a successful save means without a credible route to the target.

What remains before real-world reliance

The continuation leaves several acceptance questions open:

• No 5,000-entity exploratory capacity run or 60-minute soak was completed.
• Original-day Habit correction, void, controlled rollover, and exact-package projection-loss behavior remain open. Temporal harness results and packaged interface evidence are separate.
• The synthetic backend was independently verified alive and health-ready. Native tray, singleton, restart, reminders, memory sampling, and isolated installer acceptance remain open; a named-event graceful-shutdown check covers only that backend subcase.
• An intermittent watcher test was corrected to wait for a real native observation before editing; its freshness assertion remains unchanged. Separate coverage verifies automatic rescan recovery. These are bounded scenarios, not a universal freshness guarantee.
• Create and update latency remain above the 2-second objective.

The remaining work is to address the measured performance gap and complete the capacity, recovery, Habit, native-lifecycle, and isolated-installer checks. These gates matter because this system is intended to carry both plans and the evidence of what happened to them.

Why this review is useful

The review used synthetic records and an isolated portable package. It did not use a live vault, the current installed application, or an installer environment. The Architect accepted the bounded repository optimization, while WO-STAB-03 remained incomplete at the reviewed candidate. No final R3 acceptance, performance waiver, production installation, migration, or release is established.

For people assessing engineering judgment, the value here is a view into how reliability is earned: model the rules behind the workflow, keep source records inspectable, test complete journeys, measure the path users depend on, and leave unresolved gates visible. The work demonstrates that method and several bounded scenarios. Any productivity benefit remains an intended outcome, not a measured result.