-
Notifications
You must be signed in to change notification settings - Fork 0
Project Running Log
Canonical source:
RUNNING_LOG.md· Snapshot commit:758e55e2b66d
Purpose: Append-only project journal. Each entry narrates progress since the previous entry for an AI-agent audience. Read top-to-bottom to reconstruct the project journey.
Rule: never edit or delete prior entries. Append new entries below with ## <date> headings. Corrections to earlier claims are made in the next entry, not by rewriting history.
Related docs:
docs/product/PRODUCT-REQUIREMENTS.mddocs/design/UX-SPECIFICATION.mddocs/audits/PROTOTYPE-V5-FEATURE-AUDIT.mddocs/project/PROJECT-TRACKER.mddocs/project/PROTOTYPE-COMPLETENESS-TRACKER.mddocs/INDEX.md
Entry author: AI agent (Codex) · Triggered by: Arun's goal to address every v5 feature-audit gap through a repeating Product Manager, UI/UX Designer, Project Manager, implementation, independent QA, and incremented-version loop without waiting for further input.
There was no prior running-log entry. The starting baseline is v5 on branch prototype/calendar-ui-v5-settings at commit f74455f. The authoritative audit is docs/audits/PROTOTYPE-V5-FEATURE-AUDIT.md, which maps all 78 PRD requirements and identifies the prototype-representable gaps. The program must preserve the explicit distinction between simulated UI evidence and backend, integration, security, recovery, provider, or production evidence.
- Activated the persistent Codex goal for full audit closure; no smaller completion condition is accepted.
- Read the complete
prototypeskill and selected the UI branch because this work expands an existing interactive UI prototype. - Read the
codex-project-running-logskill and created this append-only project journal at the project root under the user's explicit autonomous-write authorization. - Started fresh specialist agents for senior product management, expert UI/UX design, and project management.
- Assigned the Project Manager to create
docs/project/PROTOTYPE-COMPLETENESS-TRACKER.mdwith feature packages, version numbers, gates, dependencies, evidence, and iteration ledger. - Assigned the Product Manager to map every representable gap into a dependency-aware roadmap and acceptance criteria.
- Assigned the Designer to specify the first proposed package: Search privacy and the complete deterministic lexical-search contract.
- All agents share this worktree. The Project Manager owns only the new completeness tracker during this iteration; Product and Design are read-only until their recommendations are reconciled by the primary agent.
- Existing v1-v5 prototype artifacts and user-owned design decisions must remain intact. Each accepted feature package receives a new version rather than modifying a prior version in place.
- V5 is a truthful, in-memory prototype and not implementation evidence.
- The audit's final coverage baseline is 9 Full, 38 Partial, 7 Placeholder, 12 Missing, and 12 Outside UI; 57 requirements need additional prototype representation.
- Search is the first safe, high-impact package because its query currently enters the URL and its required deterministic fields, filters, match explanations, history boundary, and exceptional states are incomplete.
Nothing deployed or published. The existing local v5 server is only a development preview.
Created:
-
RUNNING_LOG.md- append-only handoff journal for the autonomous completeness program.
- Reconcile the three specialist outputs into the authoritative tracker and version roadmap.
- Create the v6 versioned prototype files and branch for Search privacy/full lexical search.
- Implement all v6 Search states and interactions without changing v5 files.
- Run current-run desktop and compact browser checks, then spawn a fresh QA agent.
- Fix every QA finding, capture versioned evidence, update tracker/docs/log, and commit v6.
- Repeat the same loop for every remaining feature package until the audit has no unaddressed prototype gap.
No user decision is currently blocking autonomous progress. Product Council must resolve Timeline-versus-Almanac and visible Calendar status-label conflicts before the relevant version package; it has authority to recommend the least-divergent path while preserving explicit user decisions.
- The program is large; feature packages must remain independently reviewable and must not collapse many unverified flows into one version.
- Static CSS or screenshots alone cannot prove responsive/accessibility behavior. Every version needs direct interaction evidence proportional to its feature.
- Prototype completeness must not be described as backend, deployment, privacy, recovery, or production readiness.
- Read
docs/audits/PROTOTYPE-V5-FEATURE-AUDIT.mdanddocs/project/PROTOTYPE-COMPLETENESS-TRACKER.md. - Confirm the active branch and clean/dirty state before editing.
- Continue the currently in-progress version package; do not skip its independent QA gate.
- Append a new log entry at the end after each version is QA-complete; never rewrite this entry.
- Current phase / version: Completeness program setup; v5 audit is the baseline.
-
Active branch(es):
prototype/calendar-ui-v5-settings -
Working tree: Clean at program start;
RUNNING_LOG.mdnewly created after the snapshot. - Deployed/runtime state: No deployment. Existing local v5 preview may be running at port 4173 but is not production evidence.
- Next milestone: Council-approved v6 Search package and authoritative completeness tracker.
Entry author: AI agent (Codex) · Triggered by: completion of the first Product/Design/Project/Implementation/QA loop.
The three-role council decomposed the program into 30 stable packages from v6 through v35, with each of the 57 prototype-representable audit gaps assigned exactly once. V6 was narrowed from full lexical Search to the dependency-safe privacy correction; full Search remains v21 after History, Trash, and Suppressions.
- Recorded Product Council decisions C-01 through C-04 and the complete v6-v35 execution register in
docs/project/PROTOTYPE-COMPLETENESS-TRACKER.md. - Created the complete v6 version set without changing v5:
index-v6.html,app-v6.js,styles-v6.css,README-v6.md, council contract, handoff, current-run screenshots, and QA report. - Removed all Search-query parsing and serialization through
q; incoming legacyqis ignored and stripped into a known-safe history entry. - Kept Search input only in live JavaScript memory; reload clears it while internal navigation and Back/Forward preserve it within the open page.
- Replaced recent memories and suggested personal terms with a restrained, explicit current-scope explanation.
- Raised essential Search metadata, stacked the compact form, removed image-overlaid result provenance, and retained external accessible provenance where interpretation changes.
- Independent QA found one High issue: Enter from the Search field did not submit. The candidate gained a shared keyboard/form submission path and the same QA agent reran the full affected matrix.
- Final independent QA verdict: Pass with Critical 0, High 0, Medium 0, Low 0.
- Committed the immutable v6 implementation and evidence at
2c0fbf2.
-
npm run check:v6passed. -
git diff --checkpassed before freeze. - Fresh, result, no-result, Clear, legacy-query, Back/Forward, reload, URL/title/history/storage, focus, console, 1280/390/320, and inherited Calendar/Almanac/Settings checks passed.
-
design-qa-v6.mdrecords the independent test matrix and evidence boundary.
- An ordinary form-looking control cannot be assumed keyboard-complete; direct Enter verification belongs in every form acceptance walk.
- A narrow privacy correction can safely ship before its broader capability when the interface states the current scope and the tracker preserves the remaining requirement.
- Current-run visual evidence must use extensions matching actual encoded bytes; the browser captures were stored as JPEG files.
Nothing deployed or published. V6 is frozen as a local, fictional-data frontend prototype only.
Created:
docs/project/PROTOTYPE-COMPLETENESS-TRACKER.mddocs/prototypes/v6/COUNCIL-v6.mddocs/prototypes/CALENDAR-UI-PROTOTYPE-v6.mddesign-qa-v6.md- v6 prototype files and five current-run image captures
Updated:
docs/INDEX.mdprototypes/calendar-ui/package.jsonRUNNING_LOG.md
- Start v7
PVA-002 Calendar Contract Completionfrom frozen v6. - Reconcile the already-complete PM and Design contracts into a written v7 council decision.
- Implement the compact month/year chooser, external Today/selected/focus states, progressive attention/provenance disclosure, and Calendar keyboard/back behavior.
- Assign a fresh v7 QA agent, repair the same candidate until Pass, then freeze v7.
- Continue packages v8 through v35 under the same mandatory gates.
No owner decision blocks v7. Council C-01 already gives Arun's later image-only Calendar direction precedence over older overlay wording. The implementation council must choose the PM's twelve textual month buttons or the Designer's native controls; the PM's explicit acceptance contract is the default unless a compact usability conflict is demonstrated.
- Do not edit any v6 artifact.
- Branch from the v6 freeze record and copy the full version set to v7.
- Keep Search privacy in the regression suite.
- Append, never rewrite, the next log and tracker ledger entries.
- Current phase / version: v6 complete; v7 Product and Design gates ready for reconciliation.
-
Active branch:
prototype/calendar-ui-v6-private-searchat implementation commit2c0fbf2, with this append-only freeze record following. - Working tree: expected to contain only the freeze-record documentation until committed.
- Deployed/runtime state: no deployment; local prototype server only.
- Next milestone: v7 council approval and versioned implementation candidate.
Entry author: AI agent (Codex) · Triggered by: completion of the second Product/Design/Project/Implementation/QA loop.
Product, Design, and Project Management reconciled PVA-002 Calendar Contract Completion around Arun's approved image-only Calendar direction. Product Council retained clean cover pixels, chose an immediate-commit twelve-button month chooser, and defined distinct external Today, selection, and keyboard-focus states.
- Created the complete v7 version set without modifying any frozen v6 artifact:
index-v7.html,app-v7.js,styles-v7.css,README-v7.md, council contract, handoff, QA record, and eight current-run captures. - Added a private-content-free month/year chooser with exactly twelve
Jan–Decbuttons, draft-only year movement, safe immediate commit, explicit current/viewed semantics, focus trap/return, and honest four-digit prototype bounds. - Preserved image-only photo/artwork Calendar cells and real-photo cover precedence. Provenance, generated status, attention, and media failure remain outside pixels in safe accessible names and the Museum Margin.
- Added independent external dotted Today, solid selected, and dashed keyboard-focus perimeters with semantic
aria-current,aria-selected, and one roving tab stop. - Completed cross-month Arrow, Home/End, and Page Up/Down behavior; safe URL canonicalization; live month announcements; Back/Forward focus restoration; selected-day close behavior; and full Journal Day return behavior.
- Added ordinary empty-month and neutral media-failure fixtures, responsive drawer/sheet focus trapping, compact paper-day treatment, and tablet/mobile stacking above bottom navigation.
- Regressed the frozen v6 private Search contract, including legacy-query stripping, live-memory-only terms, generic title, Back preservation, and reload clearing.
- A read-only adversarial review found and drove repairs for history, focus, invalid URL state, compact stacking, deep-link, live-region, year-edge, and ring-geometry defects before the final QA pass.
- Independent QA passed the exact final hashes with Critical 0, High 0, Medium 0, and Low 0.
- Committed the immutable v7 implementation and evidence at
05975fc.
-
npm run check:v7passed. -
git diff --checkpassed before freeze. - Exact QA-bound SHA-256 prefixes: index
03cdafe8…, app90f2d2b8…, CSS0fe7faec…. - Month chooser, year edges, URL/title, history/focus, keyboard, clean-tile/progressive disclosure, real-cover precedence, paper/empty/failure states, light/dark, reduced motion, console, 1280/960/700/390/320, and v6 Search regression passed.
-
design-qa-v7.mdrecords the full independent test matrix and bounded evidence claims.
- A polished Calendar needs history and focus to be modeled together: selected-detail close, full-day return, and cross-month keyboard navigation each exposed different stale-state risks.
- A visual state can stay outside image pixels while remaining exact through layered boundaries, safe accessible names, and progressive detail disclosure.
- Responsive modal semantics require more than positioning; drawer stacking, background inertness, focus trapping, breakpoint focus preservation, and bottom-navigation z-order all need direct verification.
- Prototype representation limits must be named as such. The four-digit chooser boundary is not a product archive or retention limit.
Nothing deployed or published. V7 is frozen as a local, fictional-data frontend prototype only.
Created:
docs/prototypes/v7/COUNCIL-v7.mddocs/prototypes/CALENDAR-UI-PROTOTYPE-v7.mddesign-qa-v7.md- v7 prototype files and eight current-run PNG captures
Updated:
docs/project/PROTOTYPE-COMPLETENESS-TRACKER.mddocs/INDEX.mdprototypes/calendar-ui/package.jsonRUNNING_LOG.md
- Start v8
PVA-003 Cross-month Almanacfrom frozen v7. - Reconcile Product, Design, and Project contracts under approved Council decisions C-02 and C-03.
- Implement reverse-chronological cross-month groups, deterministic Load earlier, month/year jump, stable same-day navigation, and hidden/Trash-only exclusion.
- Assign a fresh v8 QA agent, repair the same candidate until Pass, and freeze v8.
- Continue packages v9 through v35 under the same mandatory gates.
No owner decision blocks v8. Council C-02 already adopts Monthly Almanac as the chronological Timeline experience, and C-03 preserves the approved Calendar/Almanac switcher.
- Do not edit any v7 artifact.
- Branch from the v7 freeze record and copy the complete version set to v8.
- Keep v6 Search privacy and v7 Calendar behavior in the regression suite.
- Append, never rewrite, the next log and tracker ledger entries.
- Current phase / version: v7 complete; v8 released for Product Council work.
-
Active branch:
prototype/calendar-ui-v7-calendar-contractat implementation/evidence commit05975fc, with this freeze record following. - Working tree: expected to contain only freeze-record documentation until committed.
- Deployed/runtime state: no deployment; local prototype server only.
- Next milestone: v8 Product/Design council and Cross-month Almanac candidate.
The Product Manager, UI/UX Designer, and Project Manager council approved PVA-003 Cross-month Almanac. The candidate now extends the approved Almanac across deterministic month boundaries without adding a Timeline tab. It is not frozen and has not yet received independent QA.
- Council resolved the initial range to August 2026 only. Each explicit
Load earlier daysadds exactly one calendar month: empty July, then June, then May. -
monthis the newest safe boundary and optionalthroughis the oldest; optionaldateanchors a chapter. Private text, scroll, and focus selectors never enter the URL. - The wide Almanac rail is now a collapsible cross-month index with safe month/day links rather than a duplicate mini-calendar. At 960 px and below it becomes a focus-trapped sheet.
- Chapters contain one Calendar Cover, generated title/summary/tags, counts, external provenance, and
Read full Journal Day. Raw source journals appear only in the canonical full-day renderer. - Real-photo cover precedence is preserved. AI/source/status/caption text remains outside image pixels.
- Hidden June 20 Trash-only and May 18 history-only synthetic records are represented outside the render data and never appear in ordinary Almanac counts, DOM, accessible names, index, or targets.
- Loading preserves existing content and the logical control. A local synthetic error keeps content intact and exposes Retry without duplicating months.
- Jump uses the inherited four-digit year row and exactly twelve text month buttons; committing resets the loaded range to that month, including truthful empty-month states.
-
npm run check:v8passes. -
git diff --checkpasses. - Direct browser walkthrough confirmed initial order; July zero-day load; June order 27/9; safe Back/Forward range restoration; canonical June full-day route and Back focus; twelve-button jump; empty July; failure/Retry; hidden sentinel absence; URL canonicalization; wide and 390 px layouts.
- Frozen v7 core file hashes still match commit
05975fcexactly.
This is fictional-data frontend evidence only. It does not establish backend query ordering/filtering, lifecycle enforcement, server pagination, persistence, authentication, media delivery, deployment, formal accessibility conformance, or production readiness.
- Assign a fresh independent v8 QA agent against the Council contract and exact candidate bytes.
- Repair every finding in the unfrozen v8 candidate and rerun affected/full checks.
- Capture final current-run evidence, record exact hashes, update tracker/QA/handoff, commit, and freeze only after Pass.
V8 independently passed with Critical 0, High 0, Medium 0, and Low 0. The allowed closure statement is limited to: LID-REF-002 prototype-represented; implementation unverified.
-
index-v8.html:0f876cf44f7f68478fa64653770ecd46bba9cd853bc6fcc3f3057e123a4ae384 -
app-v8.js:bc478af42d55df256fab8b2e9f0773d00b049a7879a12535a2a7effe11815760 -
styles-v8.css:453577e1b9c93ff63e215886b50215b8ad53a795dff5830afe47920711f19bda -
styles-v8-almanac.css:87ef6345aa6ef054d76354c5c27e901980f99478fc2802b62a8d51c8ae618007
Any byte change to those four artifacts invalidates the QA result.
- Replaced private scroll/focus browser-history payloads with an opaque
entryIdand in-memory snapshots. - Preserved exact Almanac context across Load Back/Forward, view switches, responsive remapping, rail Hide/Show, manual/device theme changes, and full-day adjacent navigation.
- Bounded ancient and distant route handling so no transition creates calendar-distance-proportional UI work.
- Restored focus for drawers, dialogs, upload completion, photo view, and artwork generation states.
- Corrected compact Read, Load, Retry, and archive-end controls to the 44 px minimum at 390 and 320 px.
- Full Council Sections 13 and 14 interaction matrix passed.
- 1280/960/700/390/320 layouts, no horizontal overflow, drawer behavior, reduced motion, 200% text zoom, and compact high-zoom observation passed within the documented v35 boundary.
- V6 private Search and frozen v7 Calendar regressions passed; v6/v7 files remained unchanged.
-
npm run check:v8andgit diff --checkpassed; tested routes produced no console warnings or errors. -
design-qa-v8.mdcontains the complete bounded QA record.
Nothing was deployed or published. V8 remains a local fictional-data frontend prototype and does not verify any backend, integration, persistence, authentication, accessibility-conformance, or production behavior.
Freeze v8 without changing the QA-bound bytes, release v9 PVA-004 First-use and Readiness, and keep every prior version immutable.
V9 independently passed with Critical 0, High 0, Medium 0, and Low 0. The implementation and evidence are immutable at ae34415; the freeze record is 5a12fb2; the final tracker record is 12e5e88.
- The default Calendar can now represent a calm empty first-use archive with five independent VoiceNotes, Telegram, AI, Backup, and Recovery Ceremony readiness lanes.
- Capture remains available when AI is unavailable. Backup remains distinct from restoration, and Recovery Ceremony remains Blocked in every v9 fixture with all three prerequisites unevidenced.
- A real local
.txtselection can create exactly one temporary Uploaded Journal without revealing the populated regression fixture or persisting any content. - Fixture choice and Search text remain page-memory-only. No hostname, callback path, identifier, credential, recovery key, or false connection/backup/restore claim appears.
- The allowed closure is limited to: First-use readiness is prototype-represented with synthetic fixtures; integrations, recovery, implementation, and operations remain unverified.
- Frozen v6–v8 behavior, responsive widths, compact reflow observations, light/dark, reduced motion, keyboard/focus, target size, URL/title/storage privacy, syntax, console, and current-run evidence passed.
- Nothing was deployed or published. V9 is a local fictional-data frontend prototype only.
- V10
PVA-005 Resilient Application Shellwas released from the queue after the freeze.
Product, Design, and Project Management approved PVA-005 Resilient Application Shell. After adversarial repair and complete fresh independent QA by /root/v10_independent_qa, v10 passed with Critical 0, High 0, Medium 0, and Low 0. The implementation/evidence commit is recorded by the following freeze entry; these are the immutable QA-bound UI identities:
-
index-v10.html:9a8a1da6fc00ff4f694cb00dba3f5784168ab1a9d45b16ca680c410d6d330428 -
app-v10.js:5e0876d7e5ce91040b7b921a1a1fe10746304ae85f39c66f001166e56b8793ca -
styles-v10.css:3f38acbe74ffdac691b5963a779b27d61f3f19e3f03775aabec626b74bb12869 -
styles-v10-almanac.css:7ca0b5ad77cef1e08681479cd1d79d9dd1dafb70e520d1e0ee04d15860b38b8b -
styles-v10-readiness.css:e2c07c35b05307ff682ed0ecb21ceb4e33fcb8b5a45f2cd227b23d86584cd42e -
styles-v10-resilience.css:d69e52e73bfb2f72c378fbed3b60e1268790cdc91c642dbae347be01b642201c
- Added coordinated initial loading, verified-month request/failure, partial-photo failure, persistent connection interruption, bounded unsaved Correction, session expiry/reauthentication, total/settled server failure, and explicit guarded Retry states.
- Operation identities coalesce rapid repeat activation and reject stale callbacks. Month history commits once, media never duplicates, Correction stays at zero until an explicit post-reconnect Retry and then exactly one, and server recovery resolves once.
- The unsaved Correction retains its draft and caret through saving/failure, guards Escape/Back/navigation/reload, and never enters URL, history payload, storage, requests, or logs.
- Session and unknown/total-failure states remove private archive DOM and inherited live/toast text. Synthetic reauthentication returns only to a generic Calendar and never imitates Cloudflare login or proves authentication.
- State priority prevents restored notices, connection failures, local failures, total server errors, and unsaved confirmation from exposing contradictory or competing primary actions.
- Responsive and accessibility repairs include compact recovery visibility, dialog/footer reflow, orientation focus reconciliation, 44 px compact primaries, dark-theme primary contrast, and the exact 700 px journal-title boundary.
- Seventeen current-run PNGs cover connection, loading, month/server/media failure, Retry phases, session/return, Correction/leave, compact and landscape states. Light/dark, reduced motion, reflow-equivalent zoom observations, semantics, keyboard/focus, privacy/network/storage, and frozen v6–v9 regressions passed.
The only permitted closure is: The resilient application shell is prototype-represented with synthetic fixtures; connectivity, server behavior, authentication, persistence, and idempotency enforcement remain unverified. Nothing was deployed or published. V11 PVA-006 Needs Date Review is the next queued milestone after the documentation-only freeze record.
The immutable v10 implementation/evidence commit is ffabe0d; the documentation-only freeze record is 497c98d. Neither freeze step changed the six independently passed UI hashes. V11 is released from the queue while all of its gates remain unstarted.
Generated from arunpr614/Life-Reflection@6b8b70b72148 · Canonical content lives in Git · Fictional prototype data only
- Life in Days — Hetzner shared-host runbook
- Life in Days — Phase1 implementation plan
- PID R10 — Conditional Object-Store Transition
- PRD R0 — Shared-Host Private Foundation
- PRD R1 — Manual Journal Archive
- PRD R2 — Telegram Photo Capture
- PRD R3 — Retrieval and Date Integrity
- PRD R4 — Source History and Lifecycle Safety
- PRD R5 — Prospective VoiceNotes Sync
- PRD R6 — Generated Text Reflection
- PRD R7 — Generated Artwork
- PRD R8 — Operational Scale and Resilience
- PRD R9 — Private Launch Acceptance and Stabilization
- Life in Days release documents
- Life in Days Phase 1 — AI agent resource index
- Codex Goal prompt — Phase 1 P0 requirements to private production
- P0 Codex Gold Goal prompt — complete P0 and R0 only
- Phase 1 GitHub Project V2 sync
- Life in Days — Phase 1 Release Plan
- Life in Days — detailed implementation plan
- Life in Days Global PRD
- Life in Days — project tracker
- Life in Days — prototype completeness tracker
- Life in Days — requirements traceability
- Life in Days — UX specification
- Life in Days — AI Artwork Model Evaluation
- Life in Days — AI Text Model Evaluation
- Initial product brief
- Life in Days: Private Media Storage Evaluation
- Requirements under discovery
- Product and integration research
- Project Git provenance
- Life in Days — proposed shared understanding
- Life in Days — Product Council planning-baseline review
- Life in Days Phase 1 — Independent QA Lead charter
- Agent charter — Project Manager
- Agent charter — Senior Product Manager
- Agent charter — Technical Architect
- Agent charter — UI/UX Design Lead
- Life in Days Phase 1 — P0 Owner Action Ledger
- Life in Days Phase 1 — P0 execution context digest
- Life in Days Phase 1 — P0 execution authorization addendum
- Life in Days Phase 1 — P0 execution council charter
- Life in Days Phase 1 — P0 execution decision ledger
- Life in Days Phase 1 — P0 task Definition of Ready
- Life in Days Phase 1 — P0 execution-control review
- P0/R0 Stage 0 control-repair candidate review dossier
- P0/R0 Stage 0 delivery checklist
- P0/R0 Stage 0 rollback and recovery plan
- P0/R0 Stage 0 state contract
- P0/R0 Stage 0 test plan
- PC-001 readiness-control hardening — planning review
- Life in Days — Phase 1 Product Council Decision Record
- Life in Days Phase 1 — source baseline
- Life in Days Phase 1 — Product Council charter
- Life in Days — Product Manager Council Review
- Life in Days — Project Manager Council Review
- Life in Days — Product Council UX Design Review
- Life in Days Product Council
- Life in Days — calendar UI prototype
- Life in Days — calendar UI prototype v2
- Life in Days — unified Calendar and Almanac prototype v3
- Life in Days — Museum Margin Calendar prototype v4
- Life in Days — private Settings and compact privacy prototype v5
- Life in Days — private Search prototype v6
- Life in Days — Calendar contract prototype v7
- Life in Days — Cross-month Almanac prototype v8
- Life in Days — First-use Readiness prototype v9
- Life in Days — Resilient Application Shell prototype v10
- Life in Days calendar UI prototype
- Life in Days calendar UI prototype v2
- Life in Days unified calendar prototype v3
- Life in Days Museum Margin prototype v4
- Life in Days Settings prototype v5
- Life in Days — private Search prototype v6
- Life in Days prototype v7 — Calendar contract completion
- Life in Days prototype v8 — Cross-month Almanac
- Life in Days prototype v9 — First-use Readiness
- Life in Days prototype v10 — Resilient Application Shell
- v6 Product Council contract — Private Search State
- Life in Days prototype v7 — Product Council contract
- Life in Days prototype v8 — Product Council contract
- Life in Days prototype v9 — Product Council contract
- Life in Days prototype v10 — Product Council contract
- Life in Days v2 — design QA
- Life in Days unified prototype v3 — design QA
- Life in Days v4 — design QA
- Life in Days v5 design QA
- Life in Days v5 design QA
- Life in Days v6 — independent design and interaction QA
- Life in Days v7 — independent design and interaction QA
- Life in Days prototype v8 — independent design QA
- Life in Days prototype v9 — independent design QA
- Life in Days prototype v10 — independent design QA
- Life in Days prototype v5 — PRD feature audit
- AI agent operating contract — keep Phase 1 alive
- Contributing to Life in Days
- GitHub Projects Roadmap — current capability research
- Life in Days — Hetzner shared-host deployment spike
- Wayfinder for Life in Days Phase 1 — adoption and GitHub integration report
- Life in Days — GitHub Projects Roadmap design spike
- ARCH-R0-001 — Product Council task readiness
- ARCH-R0-001 — task delivery checklist
- ARCH-R0-001 — task design specification
- ARCH-R0-001 — task product requirements
- ARCH-R0-001 — task QA plan
- ARCH-R0-001 — task technical plan
- ARCH-R1-001 — Product Council task readiness
- ARCH-R1-001 — task delivery checklist
- ARCH-R1-001 — task design specification
- ARCH-R1-001 — task product requirements
- ARCH-R1-001 — task QA plan
- ARCH-R1-001 — task technical plan
- ARCH-R2-001 — Product Council task readiness
- ARCH-R2-001 — task delivery checklist
- ARCH-R2-001 — task design specification
- ARCH-R2-001 — task product requirements
- ARCH-R2-001 — task QA plan
- ARCH-R2-001 — task technical plan
- ARCH-R3-001 — Product Council task readiness
- ARCH-R3-001 — task delivery checklist
- ARCH-R3-001 — task design specification
- ARCH-R3-001 — task product requirements
- ARCH-R3-001 — task QA plan
- ARCH-R3-001 — task technical plan
- ARCH-R4-001 — Product Council task readiness
- ARCH-R4-001 — task delivery checklist
- ARCH-R4-001 — task design specification
- ARCH-R4-001 — task product requirements
- ARCH-R4-001 — task QA plan
- ARCH-R4-001 — task technical plan
- ARCH-R5-001 — Product Council task readiness
- ARCH-R5-001 — task delivery checklist
- ARCH-R5-001 — task design specification
- ARCH-R5-001 — task product requirements
- ARCH-R5-001 — task QA plan
- ARCH-R5-001 — task technical plan
- ARCH-R6-001 — Product Council task readiness
- ARCH-R6-001 — task delivery checklist
- ARCH-R6-001 — task design specification
- ARCH-R6-001 — task product requirements
- ARCH-R6-001 — task QA plan
- ARCH-R6-001 — task technical plan
- ARCH-R7-001 — Product Council task readiness
- ARCH-R7-001 — task delivery checklist
- ARCH-R7-001 — task design specification
- ARCH-R7-001 — task product requirements
- ARCH-R7-001 — task QA plan
- ARCH-R7-001 — task technical plan
- ARCH-R8-001 — Product Council task readiness
- ARCH-R8-001 — task delivery checklist
- ARCH-R8-001 — task design specification
- ARCH-R8-001 — task product requirements
- ARCH-R8-001 — task QA plan
- ARCH-R8-001 — task technical plan
- ARCH-R10-001 — Product Council task readiness
- ARCH-R10-001 — task delivery checklist
- ARCH-R10-001 — task design specification
- ARCH-R10-001 — task product requirements
- ARCH-R10-001 — task QA plan
- ARCH-R10-001 — task technical plan
- AUD-001 — Product Council task readiness
- AUD-001 — task delivery checklist
- AUD-001 — task design specification
- AUD-001 — task product requirements
- AUD-001 — task QA plan
- AUD-001 — task technical plan
- ENG-R0-001 — Product Council task readiness
- ENG-R0-001 — task delivery checklist
- ENG-R0-001 — task design specification
- ENG-R0-001 — task product requirements
- ENG-R0-001 — task QA plan
- ENG-R0-001 — task technical plan
- ENG-R1-001 — Product Council task readiness
- ENG-R1-001 — task delivery checklist
- ENG-R1-001 — task design specification
- ENG-R1-001 — task product requirements
- ENG-R1-001 — task QA plan
- ENG-R1-001 — task technical plan
- ENG-R2-001 — Product Council task readiness
- ENG-R2-001 — task delivery checklist
- ENG-R2-001 — task design specification
- ENG-R2-001 — task product requirements
- ENG-R2-001 — task QA plan
- ENG-R2-001 — task technical plan
- ENG-R2-002 — Product Council task readiness
- ENG-R2-002 — task delivery checklist
- ENG-R2-002 — task design specification
- ENG-R2-002 — task product requirements
- ENG-R2-002 — task QA plan
- ENG-R2-002 — task technical plan
- ENG-R3-001 — Product Council task readiness
- ENG-R3-001 — task delivery checklist
- ENG-R3-001 — task design specification
- ENG-R3-001 — task product requirements
- ENG-R3-001 — task QA plan
- ENG-R3-001 — task technical plan
- ENG-R4-001 — Product Council task readiness
- ENG-R4-001 — task delivery checklist
- ENG-R4-001 — task design specification
- ENG-R4-001 — task product requirements
- ENG-R4-001 — task QA plan
- ENG-R4-001 — task technical plan
- ENG-R4-002 — Product Council task readiness
- ENG-R4-002 — task delivery checklist
- ENG-R4-002 — task design specification
- ENG-R4-002 — task product requirements
- ENG-R4-002 — task QA plan
- ENG-R4-002 — task technical plan
- ENG-R5-001 — Product Council task readiness
- ENG-R5-001 — task delivery checklist
- ENG-R5-001 — task design specification
- ENG-R5-001 — task product requirements
- ENG-R5-001 — task QA plan
- ENG-R5-001 — task technical plan
- ENG-R6-001 — Product Council task readiness
- ENG-R6-001 — task delivery checklist
- ENG-R6-001 — task design specification
- ENG-R6-001 — task product requirements
- ENG-R6-001 — task QA plan
- ENG-R6-001 — task technical plan
- ENG-R7-001 — Product Council task readiness
- ENG-R7-001 — task delivery checklist
- ENG-R7-001 — task design specification
- ENG-R7-001 — task product requirements
- ENG-R7-001 — task QA plan
- ENG-R7-001 — task technical plan
- EVAL-R6-001 — Product Council task readiness
- EVAL-R6-001 — task delivery checklist
- EVAL-R6-001 — task design specification
- EVAL-R6-001 — task product requirements
- EVAL-R6-001 — task QA plan
- EVAL-R6-001 — task technical plan
- EVAL-R7-001 — Product Council task readiness
- EVAL-R7-001 — task delivery checklist
- EVAL-R7-001 — task design specification
- EVAL-R7-001 — task product requirements
- EVAL-R7-001 — task QA plan
- EVAL-R7-001 — task technical plan
- PC-001 — readiness-control hardening Council record
- PC-001 — readiness-control hardening delivery plan
- PC-001 — readiness-control evidence design specification
- PC-001 — readiness-control hardening product requirements
- PC-001 — readiness-control hardening QA plan
- PC-001 — readiness-control hardening technical plan
- PID-R10-001 — Product Council task readiness
- PID-R10-001 — task delivery checklist
- PID-R10-001 — task design specification
- PID-R10-001 — task product requirements
- PID-R10-001 — task QA plan
- PID-R10-001 — task technical plan
- PRD-R0-001 — Product Council task readiness
- PRD-R0-001 — task delivery checklist
- PRD-R0-001 — task design specification
- PRD-R0-001 — task product requirements
- PRD-R0-001 — task QA plan
- PRD-R0-001 — task technical plan
- PRD-R1-001 — Product Council task readiness
- PRD-R1-001 — task delivery checklist
- PRD-R1-001 — task design specification
- PRD-R1-001 — task product requirements
- PRD-R1-001 — task QA plan
- PRD-R1-001 — task technical plan
- PRD-R2-001 — Product Council task readiness
- PRD-R2-001 — task delivery checklist
- PRD-R2-001 — task design specification
- PRD-R2-001 — task product requirements
- PRD-R2-001 — task QA plan
- PRD-R2-001 — task technical plan
- PRD-R3-001 — Product Council task readiness
- PRD-R3-001 — task delivery checklist
- PRD-R3-001 — task design specification
- PRD-R3-001 — task product requirements
- PRD-R3-001 — task QA plan
- PRD-R3-001 — task technical plan
- PRD-R4-001 — Product Council task readiness
- PRD-R4-001 — task delivery checklist
- PRD-R4-001 — task design specification
- PRD-R4-001 — task product requirements
- PRD-R4-001 — task QA plan
- PRD-R4-001 — task technical plan
- PRD-R5-001 — Product Council task readiness
- PRD-R5-001 — task delivery checklist
- PRD-R5-001 — task design specification
- PRD-R5-001 — task product requirements
- PRD-R5-001 — task QA plan
- PRD-R5-001 — task technical plan
- PRD-R6-001 — Product Council task readiness
- PRD-R6-001 — task delivery checklist
- PRD-R6-001 — task design specification
- PRD-R6-001 — task product requirements
- PRD-R6-001 — task QA plan
- PRD-R6-001 — task technical plan
- PRD-R7-001 — Product Council task readiness
- PRD-R7-001 — task delivery checklist
- PRD-R7-001 — task design specification
- PRD-R7-001 — task product requirements
- PRD-R7-001 — task QA plan
- PRD-R7-001 — task technical plan
- PRD-R8-001 — Product Council task readiness
- PRD-R8-001 — task delivery checklist
- PRD-R8-001 — task design specification
- PRD-R8-001 — task product requirements
- PRD-R8-001 — task QA plan
- PRD-R8-001 — task technical plan
- PRD-R9-001 — Product Council task readiness
- PRD-R9-001 — task delivery checklist
- PRD-R9-001 — task design specification
- PRD-R9-001 — task product requirements
- PRD-R9-001 — task QA plan
- PRD-R9-001 — task technical plan
- QA-R8-001 — Product Council task readiness
- QA-R8-001 — task delivery checklist
- QA-R8-001 — task design specification
- QA-R8-001 — task product requirements
- QA-R8-001 — task QA plan
- QA-R8-001 — task technical plan
- QA-R9-001 — Product Council task readiness
- QA-R9-001 — task delivery checklist
- QA-R9-001 — task design specification
- QA-R9-001 — task product requirements
- QA-R9-001 — task QA plan
- QA-R9-001 — task technical plan
- REL-R0-001 — Product Council task readiness
- REL-R0-001 — task delivery checklist
- REL-R0-001 — task design specification
- REL-R0-001 — task product requirements
- REL-R0-001 — task QA plan
- REL-R0-001 — task technical plan
- REL-R1-001 — Product Council task readiness
- REL-R1-001 — task delivery checklist
- REL-R1-001 — task design specification
- REL-R1-001 — task product requirements
- REL-R1-001 — task QA plan
- REL-R1-001 — task technical plan
- REL-R2-001 — Product Council task readiness
- REL-R2-001 — task delivery checklist
- REL-R2-001 — task design specification
- REL-R2-001 — task product requirements
- REL-R2-001 — task QA plan
- REL-R2-001 — task technical plan
- REL-R3-001 — Product Council task readiness
- REL-R3-001 — task delivery checklist
- REL-R3-001 — task design specification
- REL-R3-001 — task product requirements
- REL-R3-001 — task QA plan
- REL-R3-001 — task technical plan
- REL-R4-001 — Product Council task readiness
- REL-R4-001 — task delivery checklist
- REL-R4-001 — task design specification
- REL-R4-001 — task product requirements
- REL-R4-001 — task QA plan
- REL-R4-001 — task technical plan
- REL-R5-001 — Product Council task readiness
- REL-R5-001 — task delivery checklist
- REL-R5-001 — task design specification
- REL-R5-001 — task product requirements
- REL-R5-001 — task QA plan
- REL-R5-001 — task technical plan
- REL-R6-001 — Product Council task readiness
- REL-R6-001 — task delivery checklist
- REL-R6-001 — task design specification
- REL-R6-001 — task product requirements
- REL-R6-001 — task QA plan
- REL-R6-001 — task technical plan
- REL-R7-001 — Product Council task readiness
- REL-R7-001 — task delivery checklist
- REL-R7-001 — task design specification
- REL-R7-001 — task product requirements
- REL-R7-001 — task QA plan
- REL-R7-001 — task technical plan
- REL-R8-001 — Product Council task readiness
- REL-R8-001 — task delivery checklist
- REL-R8-001 — task design specification
- REL-R8-001 — task product requirements
- REL-R8-001 — task QA plan
- REL-R8-001 — task technical plan
- REL-R9-001 — Product Council task readiness
- REL-R9-001 — task delivery checklist
- REL-R9-001 — task design specification
- REL-R9-001 — task product requirements
- REL-R9-001 — task QA plan
- REL-R9-001 — task technical plan
- REL-R10-001 — Product Council task readiness
- REL-R10-001 — task delivery checklist
- REL-R10-001 — task design specification
- REL-R10-001 — task product requirements
- REL-R10-001 — task QA plan
- REL-R10-001 — task technical plan
- SPK-R0-001 — Product Council task readiness
- SPK-R0-001 — task delivery checklist
- SPK-R0-001 — task design specification
- SPK-R0-001 — task product requirements
- SPK-R0-001 — task QA plan
- SPK-R0-001 — task technical plan
- SPK-R5-001 — Product Council task readiness
- SPK-R5-001 — task delivery checklist
- SPK-R5-001 — task design specification
- SPK-R5-001 — task product requirements
- SPK-R5-001 — task QA plan
- SPK-R5-001 — task technical plan
- UX-R0-001 — Product Council task readiness
- UX-R0-001 — task delivery checklist
- UX-R0-001 — task design specification
- UX-R0-001 — task product requirements
- UX-R0-001 — task QA plan
- UX-R0-001 — task technical plan
- UX-R1-001 — Product Council task readiness
- UX-R1-001 — task delivery checklist
- UX-R1-001 — task design specification
- UX-R1-001 — task product requirements
- UX-R1-001 — task QA plan
- UX-R1-001 — task technical plan
- UX-R2-001 — Product Council task readiness
- UX-R2-001 — task delivery checklist
- UX-R2-001 — task design specification
- UX-R2-001 — task product requirements
- UX-R2-001 — task QA plan
- UX-R2-001 — task technical plan
- UX-R3-001 — Product Council task readiness
- UX-R3-001 — task delivery checklist
- UX-R3-001 — task design specification
- UX-R3-001 — task product requirements
- UX-R3-001 — task QA plan
- UX-R3-001 — task technical plan
- UX-R4-001 — Product Council task readiness
- UX-R4-001 — task delivery checklist
- UX-R4-001 — task design specification
- UX-R4-001 — task product requirements
- UX-R4-001 — task QA plan
- UX-R4-001 — task technical plan
- UX-R5-001 — Product Council task readiness
- UX-R5-001 — task delivery checklist
- UX-R5-001 — task design specification
- UX-R5-001 — task product requirements
- UX-R5-001 — task QA plan
- UX-R5-001 — task technical plan
- UX-R6-001 — Product Council task readiness
- UX-R6-001 — task delivery checklist
- UX-R6-001 — task design specification
- UX-R6-001 — task product requirements
- UX-R6-001 — task QA plan
- UX-R6-001 — task technical plan
- UX-R7-001 — Product Council task readiness
- UX-R7-001 — task delivery checklist
- UX-R7-001 — task design specification
- UX-R7-001 — task product requirements
- UX-R7-001 — task QA plan
- UX-R7-001 — task technical plan
- Life in Days — document index
- Life in Days
- Life in Days - Running Log
- Publication provenance
- Pull-Request-Template
- Life in Days
- Security and privacy reporting