Joe, I would build a small personal-admin system with an assistant attached. I would not build a general-purpose system that continuously collects, interprets and maintains a model of your life.
The distinction matters here. Your valuable outcomes are concrete: a claim does not get forgotten, a financial decision arrives with its evidence, a promise becomes a recorded commitment, and you can find the mortgage terms without reconstructing a conversation. The system should earn its complexity by delivering those outcomes.
PART 1 — GREENFIELD
- The components I would build
A. One operational store, with one phone interface
Use SQLite for commitments, watches, recurring reviews, accounts, agreements and their operational dates. Put a thin web app and a shared command interface in front of it.
The app would show:
Now: work you have chosen to progress. Waiting: who owes the next move, and when to review it. Upcoming: genuine deadlines, appointments and decision windows. Later: retained intentions that are not current commitments. Records: the relevant agreement, case or note behind an item.
Every commitment has a stable identity, a finish condition and an owner. Dates are optional; their meaning is not. A deadline, a chosen start date and a “check whether they replied” date are different fields.
This store is not a document archive, a transcript repository, a medical record or an investment-pricing database. I would not turn it into a universal “facts about everything” engine.
A custom implementation is justified only by your particular distinction between work, waiting, watches and sourced dates. A conventional task app plus linked notes would take roughly half a working day to configure and would be my cheaper baseline. A thin custom version is several working days of engineering and testing. Your existing Simple Tasks app already appears close enough that rebuilding it would be wasteful.
B. A small Markdown knowledge library
Use Markdown for explanation, judgement and personal context. Keep it in Git.
The mortgage explanation belongs here. So do the history of the EgyptAir claim, your therapy reflections, why you chose an interest-only mortgage, and the instructions for recovering the system.
Markdown is not the operational task database. It must not contain another maintained list of outstanding actions or another independently maintained balance.
The front door would have stable subject links, not running commentary. “Mortgage” is a useful index entry. “Mortgage review expected soon” is state copied into navigation.
I would use ordinary folders and links. No knowledge-graph visualisation, conformance programme or requirement to link every source both ways. A broken-link check is useful; making a personal library conform to an elaborate knowledge format is not an outcome you need.
C. Original evidence in its existing kind of store
Documents belong in a document archive. Photos belong in a photo library. Financial imports belong in dated, preserved source files. Health measurements belong in a measurement store.
The task app links to these records; it does not ingest everything into itself.
For your scale, Paperless is a reasonable document archive. Google Photos remains the primary photo library if that is your chosen arrangement; Immich is an explicitly secondary copy. I would not pretend that two photo products automatically constitute a tested backup.
D. One foreground assistant
Hermes handles research, explanation, drafting, filing authorised commitments and carrying out approved work. It uses narrow tools against the stores above.
It is not the scheduler for judgement about your life. It does not wake up to invent tasks, write speculative reply drafts, distil your personality or produce unsolicited diary entries.
Every successful filing ends with a compact receipt: what was recorded, where, and its identity. “Added” without a verified record is not an acceptable completion.
E. Home Assistant as a separate operational domain
Home Assistant owns heating, sensors and household automation. The assistant can inspect it and carry out authorised changes, but the personal-admin system is not required for the house to function.
Critical heating and safety behaviour must survive a dead VM, an unavailable model and broken internet access. Physical controls remain usable. A wall dashboard may display task data, but it cannot become another owner of it.
F. A modest reliability layer
Use service supervision, bounded deterministic jobs, consistent backups and an independent failure signal on the HA box.
Do not run a second autonomous personal assistant as the recovery mechanism. A second process learning and interpreting a competing personal corpus increases the ambiguity you are trying to remove. The HA box needs enough independent monitoring to tell you the VM is down, not another personality.
For greenfield, I would not add Open WebUI memory replication, a second personal RAG corpus or a standby learning agent. Those are more serving paths and recovery dependencies without an evidenced need in this dossier.
- Where the records live
“One home” means one authoritative maintained representation. A document and a note explaining it can coexist; two independently maintained claims to the current truth cannot.
Standing identity and preferences
Home: USER.md. Author: you, or the assistant recording something you explicitly stated or confirmed. Serving: a short deterministic prompt projection.
The projection contains routine constraints: your identity, working hours, approval boundaries and how you want work delivered. It does not carry case histories, balances, rates or detailed family dossiers. I would deliberately leave headroom instead of treating the character limit as a target.
Durable facts about your life
Home: sourced subject notes in the Markdown library. Evidence: the original message, document or other identified source.
A useful fact about your degree or a relationship can be compiled into a note when it becomes worth retaining. I would not start greenfield with a separate semantic personal-memory database.
That loses automatic recall of uncompiled conversational detail. I accept that loss. Explicit conversation search is a cheaper and more inspectable fallback than maintaining a second account of your life.
Money and mortgage
Home for current operational terms: structured account and agreement records in SQLite. Home for observations: dated financial source records. Home for reasoning: a finance strategy note and a mortgage explanation. Evidence: original lender documents, provider statements and transaction imports.
These are distinct record types, not duplicates. A mortgage agreement owns the product-end date. A statement owns an observed debit. A scenario calculation owns an assumed future payment. The prose explains their implications.
I would use a few concrete tables, not build a general financial knowledge graph. A sourced agreement record plus dated observations is sufficient for your mortgage, bills and stoozing cards.
Commitments and deadlines
Home: SQLite. Calendar appointments: Google Calendar. Calendar copies of task deadlines: owned projections from SQLite.
A dentist appointment entered in Google Calendar remains a Google event. An accepted card-expiry watch remains a SQLite record. The app can show both without making either overwrite the other.
This rejects the idea that every date must originate in one database. Each record has one owner; the combined view is not an owner.
Health
Home: a small health measurement store, separate from tasks. Greenfield implementation: a dedicated SQLite database with CSV export. Anxiety and reflective accounts: attributed notes, not numeric measurements.
Measurements retain actual or estimated timestamps, source and corrections. Reports are generated. A task can say “send the agreed BP readings to the clinician”; it cannot become the blood-pressure record.
For the existing estate, I would not migrate working CSV and CouchDB sources merely to achieve this greenfield tidiness. The current domain ownership is already close to right.
Therapy and diary
Home: private Markdown source notes, with separate compiled reflections. Authorship: explicitly distinguish your words, Jade’s reported words and the assistant’s interpretation.
An unresolved feeling does not become an overdue task. A practice becomes an action only if you actually agree to do it.
I would not create an agent diary. Existing agent reflections can remain historical material, clearly attributed and excluded from default factual retrieval. They are not evidence of what you believe.
Conversation transcripts
Home: Hermes’s conversation store. Purpose: continuity, explicit historical search, provenance and debugging.
Transcripts are evidence that something was said, not proof it remains true. They are not injected wholesale, nightly rewritten into life facts or mirrored into several chat products.
Derived indexes and embeddings
Home: a disposable cache directory. Authority: none.
Start with full-text search. Add semantic retrieval only after a repeatable set of real questions demonstrates that full-text search and subject routing fail. If added, embeddings point to current source identities and versions. Deleting the index must not lose a personal fact.
- Who writes what
You and the foreground assistant write interpretations, decisions and accepted commitments. The assistant must preserve attribution and verify operational writes.
Deterministic collectors write observations: a portal response, an imported transaction, a health reading, a provider valuation. Collection must not silently convert an observation into a conclusion. “Email mentions a payment” is not “payment reconciled.”
Machines generate reports and reading copies. Each output identifies its owner, source time and generation status. A failed refresh leaves visibly stale information, not a page that looks current because it was opened today.
I would generate most Markdown reports on demand or after source changes. I would not rewrite them hourly merely to keep a second reading surface warm. Kindle exports are generated when preparing or delivering a reading packet.
Original evidence is preserved with appended corrections. Privacy deletion is an exception: “append-only evidence” must never mean that forgotten sensitive material is silently restored from an old backup.
- Scheduling: ten recurring jobs, zero scheduled model runs
For the greenfield personal-admin core, I would budget ten recurring jobs. That is an engineering target, not a magic ceiling for all household devices and applications.
The ten are:
-
Reminder dispatcher Checks accepted reminder times and review dates. One-shot reminders are records, not individually maintained cron definitions.
-
Morning briefing Your 08:00 view: genuine deadlines, waiting items needing attention and chosen work. No routine financial narration.
-
Evening exception pass Reports missed timed commitments or a relevant unresolved failure. Silent when there is nothing useful to say.
-
Weekly review packet Presents untriaged captures, waiting items, upcoming decision windows and candidates for “Now.” Does not choose new obligations for you.
-
Correspondence ingestion Collects relevant notices and case correspondence with provenance. Ambiguous classification stays pending.
-
Daily domain collection Runs the required finance, case and health collectors in dependency order. Independent steps have separate outcomes and can fail independently.
-
Nightly backup Consistent database snapshots, incremental off-host backup and a recorded manifest.
-
Independent infrastructure watchdog Checks the VM, storage pressure, backup age and critical services from outside the VM.
-
Weekly restore check Restores a rotating selection into isolation and verifies that the application can read it.
-
Weekly housekeeping Expires caches and scratch, checks broken links and retired consumers, and stages updates for an attended maintenance session.
This must not be a trick where 112 opaque scripts are hidden behind ten names. There are still named work units, timeouts, logs, retry policies and freshness requirements. The reduction comes from deleting unnecessary work, replacing polling with events and eliminating duplicated pipelines—not just wrapping the existing list in a larger script.
Household events belong in HA or the relevant service. A safety monitor is not removed to meet a job-count target. Conversely, an hourly browser-default reset is not justified merely because it is deterministic.
The categories I would not schedule are:
Speculative email and WhatsApp drafting. Conversational fact extraction and personality synthesis. Agent diary or “thinking” maintenance. Repeated narration of unchanged state. Generic autonomous failure repair. Repeated authentication checks for services nobody currently needs. Permanent experiments without a question and an end date. Daily application updates across the estate.
Failure detection remains automatic. Known, bounded recovery actions can be automatic. Unfamiliar diagnosis belongs in an incident packet for a foreground session, not an agent called every few hours.
- Dates: stop using urgency to compensate for selection
I would not add dates to the 47 undated items merely to make the calendar look populated.
“Fix bed,” “boarding attic” and “use York gift card” do not become better-managed commitments because a system assigns them Friday. Invented dates train you to ignore real ones.
Instead, the weekly interaction asks one consequential question: “Which retained items are you actually taking on now?” Keep a small active set. Everything else stays explicitly Later, Waiting or a watch.
A real expiry must be investigated and recorded. “Use York gift card” needs an expiry check if one exists; it does not need a fabricated deadline. “Return blind to Dunelm” needs disposition of the apparently elapsed return window, not another postponement.
The nearest recorded deadline being 7 December is not inherently a problem. The problem is whether consequential windows are absent. The Virgin transfer-qualification window identified in section 11 is an example of a possible omission. Resolve its source before declaring the next month clear.
This is a change in what the system asks of you, not a date-filling exercise.
- The interface you touch
Use the phone app for ordinary capture, completion, waiting status and looking ahead. Use chat for research, judgement, drafting and issuing commands. Use Google Calendar for appointments.
Keep a Notes tab in the same app. Your request to edit Markdown there is sensible consolidation of access, not evidence that you want another application.
But remove unrestricted file editing from the ordinary task workflow:
Editable notes can be edited. Generated views are read-only and offer “change the source.” Historical evidence is read-only. Operational records open the appropriate structured form.
The existing etag refusal, atomic replacement and previous-version preservation are good engineering. They protect bytes. They do not protect meaning when a frozen tracker is still presented as a current editable list.
You should never have to touch scheduler definitions, reconcile two task lists, know which memory database a process selected, or recover an overwritten file to establish whether an action was recorded.
A short weekly review is reasonable. Daily maintenance of the maintenance system is not.
- What I would deliberately not build
I would not build:
A semantic autobiography. A second autonomous personal-memory owner. A universal record ontology spanning payments, emotions, photos and heating. Bidirectional Markdown/task synchronisation. A calendar populated with invented task dates. A routine agent-written diary. A knowledge graph as a required navigation system. A new dashboard for each new collector. Employer-data automation to fill the empty Work tag. Another energy optimiser before the existing heating experiment earns a conclusion.
I would refuse later additions that have no named outcome, owner, authoritative store, failure behaviour and retirement condition. A price watch can qualify: defined item, threshold and expiry. “Continuously look for useful opportunities” does not.
I would also refuse any feature whose correctness depends on the model remembering to obey a boundary that the storage or tool layer could enforce.
- Backups: keep recoverability, remove archaeology
The existence of 13 GB of backups does not establish excess. Your photo copy is much larger, and this dossier does not establish the available capacity, deduplication or recovery coverage.
What is disproportionate is retaining overlapping full archives, downloadable model caches and indefinite project snapshots without a declared purpose.
I would keep:
Consistent backups of operational databases and conversation history. Notes, original documents and unique application metadata. Configuration, deployment definitions and a recoverable credential bootstrap. The current privacy/suppression ledger. A short local recovery window and encrypted off-host copies. A small set of deliberately retained recovery checkpoints.
My starting retention would be seven daily, four weekly and six monthly recovery points in a deduplicating repository, adjusted to measured capacity and restore needs. Project snapshots expire after their acceptance and rollback window. Downloadable caches are excluded.
The simpler alternative is to keep the current backup tools and add exclusions, retention and restore verification. That is roughly half to one working day and should precede any backup-platform replacement. I would not introduce a new backup product unless the existing tools cannot produce consistent, restorable copies.
The HA box should hold or reach a minimal recovery entrance that does not require the failed VM, its DNS stack or its password manager to be working first.
-
Failure modes, ranked for your actual 3am
-
Storage exhaustion or host failure takes the assistant and its monitoring down together. Design response: independent monitoring, storage headroom and an offline recovery entrance. The thin-pool incident makes this a concrete concern, not generic disaster planning.
-
Recovery copies exist but cannot restore the current system. Design response: application-level restore tests, dependency bootstrap and explicit preservation of post-cutover changes and privacy state.
-
The system confidently displays the wrong current truth. Design response: one writer, visible freshness and source-labelled observations. A stale task view or assumed mortgage rate is more dangerous than an obvious error.
-
A commitment is acknowledged but never filed, or a deadline is absent. Design response: write receipts, stable identities, reconciliation and explicit waiting reviews.
-
A maintenance action breaks several services at once. Design response: attended update batches, bounded rollback and no autonomous restart of the gateway.
-
Credentials, internet or model access fail. Design response: local task access, deterministic reminders and household controls that remain independent of the assistant.
-
Alerts become routine noise. Design response: one incident identity, deduplicated escalation and silence on unchanged healthy state.
-
Sensitive material leaks across contexts or returns after forgetting. Design response: scoped retrieval, no default therapy/transcript injection and suppression-aware recovery.
Your system should be recoverable without a model. The model is useful assistance during recovery, not a prerequisite for it.
PART 2 — DISTANCE FROM TODAY
- First, correct the evidence
The dossier contains incompatible snapshots. The right conclusion is not that everything is unknowable; it is that completed migrations cannot be inferred from architectural prose.
Task authority is already substantially implemented
Sections 3 and 4 say SQLite owns tasks and the app, digest, evening close and wall display share it. Therefore T2’s description of two equal live task stores is overstated.
However, section 4 also names a kidney process that can still write the old life-admin file and Kindle/RAG consumers still reading frozen originals. That is an incomplete cutover, not a need to choose the winner again.
SQLite has already won. Finish the cutover.
The deletion rationale for generated task files is backwards
Section 10 calls generated task exports stale duplicates superseded by the “real” trackers. Sections 3 and 4 explicitly call those trackers frozen and non-authoritative.
Length does not establish authority. A shorter generated list may correctly omit completed, trashed or non-task material.
Deleting unused exports can be harmless. Calling the frozen originals the superior current source is not harmless. The missing evidence is a consumer-level comparison of current IDs and states, plus the publication job’s actual behaviour after deletion.
The file totals do not reconcile
The reported before/after Markdown totals do not reconcile with the reported deletion count. The maps also describe a different-sized estate.
A path manifest with timestamps, inclusion rules and create/delete operations would settle this. Neither “every file mapped” nor the precise surviving total should be treated as verified from this dossier.
The memory totals do not identify the serving memory
Section 14 reports the large corpus. Section 8 describes a selected guarded store with nine rows and expressly prohibits restoring the legacy database as fallback. Sections 9 and 14 also give materially different memory sizes.
Those could be different paths, different scopes or different generations. The dossier cannot establish which.
The decisive evidence remains exactly what section 8 requested: tool-handling PID, loaded modules, resolved database path and active configuration. A count returned by some database is not evidence that the gateway uses it.
The observed injection is a real acceptance failure
Taking section 14’s observation as reported evidence, SIPP-fee material appeared during unrelated questions. That fails the agreed no-prefetch outcome.
The likely mechanism is an automatic retrieval path admitting weakly relevant candidates—or failing to withhold them when relevance is absent. A small or poorly routed corpus can aggravate that. But the dossier does not establish whether the particular cause is fixed prefetch, hybrid-ranking weights, stale serving code, a replica or another injection hook.
“Source verified” addresses provenance. It does not establish relevance. Embeddings cannot fix a policy that insists on supplying personal memories when none belongs.
The immediate decision does not depend on diagnosing the exact ranking defect: turn automatic episodic/fact injection off and verify the prompt in a fresh conversation.
The survey overclaims safety and health
“No missing scripts” does not mean jobs work. “No duplicate skill names” does not establish useful or non-conflicting procedures. An exited embedding container is not necessarily an error, but neither is its irrelevance established merely by being stopped. Listening-port counts establish neither exposure nor health.
Likewise, old repair directories are not proved disposable because similarly named current data exists. They may contain unique provenance, rollback state or privacy records. “Reversible because it can be rerun” is false for historical evidence that cannot be recreated.
The identical Immich cache archives are strong deletion candidates. “Zero risk” still requires confirming that backup manifests and recovery procedures do not depend on their paths. The sensible result is exclusion from future backups, not merely deleting two copies once.
The cron arithmetic has a scope problem
The inventory includes a disabled agent extraction job in addition to the three enabled agent jobs. The headline “108 scripts, 3 agent jobs” therefore mixes total definitions with enabled-agent counts.
Section 9 also mislabels its disabled-job subgroups relative to the names listed. Use the definitions file for a corrected classification.
The scheduled model-run estimate is not a spend measurement. Model identities, actual invocations, retries and billing would be needed to establish cost. Cron-failure-triage is the most frequent listed scheduled agent; that does not prove it is the most expensive.
Disabled memory consolidation is deliberate
Section 9’s suggestion that memory may be “collecting without being distilled” conflicts with section 8. Raw sync and consolidation are intentionally disabled under the guard.
Do not reactivate them to improve statistics. That would undo a safety decision, not repair an omission.
The mortgage page is useful, but not a clean factual model
It is good evidence that source-linked explanation is valuable. It is also evidence of the limits of mixed prose maintenance.
The page warns that the Bank Rate margin is assumed, yet its rate-history ledger presents the inferred new mortgage rate and payment without an equally clear observed-versus-modelled distinction. It also says to verify the first lender statement.
Its claim that the counterfactual comparison is “settled” after one rate move is too strong: the remaining future rate path is not settled. Its discussion of the unavailable Nationwide offer also continues alongside later corrections explaining why it was not a real choice.
I am not validating the dossier’s market-news claims. Their original sources are not supplied here.
Keep the explanation. Separate lender-confirmed terms, dated observations and scenarios. Do not adopt this page wholesale as a template for current financial truth.
The prune demonstrates unwanted publication, not proven non-use
Your words establish dissatisfaction. They do not establish how often every surviving component is used.
Two same-day research notes were proposed for deletion partly because nothing linked to them. That is evidence of a weak publication process, not evidence that the research had no value. Conversely, an indexed file can still be useless.
The structural answer is an active/reference/archive lifecycle, with explicit publication into the active library. It is not a bigger map promising that all retained material deserves attention.
Finally, state.db size and message counts do not measure usefulness
They cannot tell us how often mortgage answers read the conversation store, which sessions were human-facing, or what proportion of messages were tool traffic. The daily message-rate claim needs a stated observation window.
The mortgage question should route to its domain note and source documents. Conversation history is the fallback for “what did I say then?”, not the normal serving database for mortgage terms.
- Component verdicts
Costs below are engineering estimates, not measured completion times. Each verdict describes the significant gap, not every possible improvement.
- Simple Tasks operational core — SAME
SQLite ownership, stable identities, shared selection and structured dates are the right centre. Keep the existing application. No replacement project.
- Legacy trackers and their consumers — ONE CHANGE AWAY
Single change: enforce the SQLite cutover at every writer and reader, including kidney administration, Kindle, RAG and deleted exports.
Cost: half to one working day if the published interfaces work as described.
Do not add bidirectional sync. Retain originals only as labelled history. Delete compatibility publications altogether if no real consumer needs them.
- Commitment capture — ONE CHANGE AWAY
Single change: make verified task/decision receipts part of the foreground filing path.
Cost: 3–6 hours.
The shared command interface already exists. Another inbox or extraction cron loses to using it correctly.
- Backlog and date interaction — ONE CHANGE AWAY
Single change: make the review distinguish Now, Later, Waiting and genuine date-bearing watches, then reconcile the consequential missing or elapsed windows.
Cost: roughly half a working day, including a review with you.
Do not date-fill the backlog. Test the Google cancellation reminders, Virgin qualification window and the old Dunelm/Home Connect items against current state.
- Calendar and preparation — ONE CHANGE AWAY
Single change: attach accepted preparation actions to confirmed events while retaining source ownership.
Cost: 3–5 hours.
The calendar projection already exists. A second calendar or a replacement calendar engine would solve the wrong problem.
- Phone app and Markdown access — ONE CHANGE AWAY
Single change: make the Notes/Files interface enforce record roles rather than allowing every Markdown file to behave like an editable note.
Cost: 3–6 hours.
Keep the consolidation you requested. The cheaper alternative—remove editing entirely—would discard useful access you explicitly want.
- USER.md and deterministic projection — ONE CHANGE AWAY
Single change: restrict the injected projection to routinely necessary context and leave substantial headroom.
Cost: 1–3 hours, including fresh-conversation checks.
The canonical-file-plus-projection design is already correct. A new profile store would recreate the drift repaired on 5 November.
- Automatic personal-memory injection — SHOULD BE DELETED
Single change: remove automatic fact/episode prefetch from the actual serving path and prove its absence in fresh prompts.
Cost: 2–4 hours if the admitted control is already available; otherwise consume the bounded repair budget in section 8.
Keep the small standing profile. Do not replace prefetch with another relevance-tuning project.
- Secondary guarded Mnemosyne — ONE CHANGE AWAY
Single change: finish the already agreed admission gate against the actual serving process, or leave the store offline if it fails.
Cost: the existing one-working-day repair ceiling, not a new programme.
I would omit it greenfield. Given the existing corpus and agreed repair, one bounded attempt is reasonable. Corpus migration or provider replacement is not.
- Workspace publication and navigation — NEEDS REBUILD
Single change: replace “everything retained is part of the active workspace” with explicit active, reference and archive publication states.
Cost: half to one working day for the current small corpus.
This is a rebuild of lifecycle and visibility, not a rewrite of all notes. The cheaper alternative—one short index and an archive exclusion rule—is sufficient. I would not execute the twelve-order folder reorganisation as the next project.
- Graph/format maintenance as a required workflow — SHOULD BE DELETED
Single change: remove graph generation and conformance from the critical maintenance path; retain a simple link check.
Cost: 2–4 hours to disentangle consumers and preserve any useful output.
A small personal library does not need a continuously maintained representation of its own structure.
- Money, agreements and register semantics — ONE CHANGE AWAY
Single change: complete the separation of agreements, notices, receipts and payments using concrete sourced records.
Cost: 1–2 working days for the described estate, with your approval of changed financial meanings.
Do not build a universal fact platform. The simpler alternative is a few structured tables with generated register views.
- Finance and mortgage reporting — ONE CHANGE AWAY
Single change: separate observed facts from assumptions and generate repeated current figures from their owners.
Cost: about one working day for the core mortgage/stoozing/cashflow reports; broader historical reconciliation may take longer.
Keep the useful explanation. A full finance-app rebuild loses to repairing the existing reports’ inputs.
- Health sources and collection — SAME
The CSV/CouchDB/domain-collector split has explicit ownership and preserves source measurements. Do not centralise it for architectural symmetry.
Additional measurement programmes need an actual clinical or personal question, not another collector.
- Therapy and anxiety material — ONE CHANGE AWAY
Single change: offer one on-demand preparation view from attributed sources, excluding assistant interpretations from factual authority.
Cost: 1–3 hours.
No new therapy scheduler, compliance dashboard or invented practice log.
- Agent diary and routine self-reflection production — SHOULD BE DELETED
Single change: remove any active production route and exclude historical agent reflections from default personal-fact retrieval.
Cost: 1–2 hours.
Preserve existing material if you want it. Its existence does not justify producing more.
- Scheduled email and WhatsApp drafts — SHOULD BE DELETED
Single change: retire the two schedules and retain drafting on demand.
Cost: 1–2 hours including checking downstream expectations.
There is no demonstrated need here for speculative drafts delivered before you have chosen to reply.
- Scheduled agent failure triage — ONE CHANGE AWAY
Single change: replace periodic model invocation with the existing deterministic failure packet and an explicit incident escalation route.
Cost: 2–4 hours.
Failure detection stays. Known safe repairs stay. General autonomous diagnosis does not.
- Remaining scheduler estate — NEEDS REBUILD
Single change: replace the flat accreted inventory with owned pipelines and event-driven service behaviour, deleting redundant work rather than merely renaming it.
Cost: 2–4 working days across this estate.
Do not reduce the live system to ten jobs in one pass. First remove the clearly unnecessary categories; then consolidate one domain at a time with output parity and failure tests.
- Backup policy and recovery proof — NEEDS REBUILD
Single change: make backups source-scoped, retention-bound and demonstrably restorable.
Cost: 1–2 working days, including an isolated restore.
The existing backup mechanisms may remain. Deleting a few gigabytes is a useful consequence, not the acceptance criterion.
- HA and household ownership — SAME
Keeping live behaviour in HA and explanatory notes outside it is correct. The dossier does not justify replacing this boundary.
- Independent recovery signal — MISSING
Single change: prove an HA-side watchdog and recovery entrance that still work with the VM unavailable.
Cost: half to one working day.
There are Beetroot and HA health jobs, but the dossier does not demonstrate this independence. “Missing” here means the required demonstrated capability is absent from the evidence; do not deploy a duplicate if an isolation test proves it already exists.
- Paperless and photo-library roles — SAME
A document archive and an explicitly secondary Immich copy are reasonable. Do not consolidate them into the task app or memory database.
This verdict concerns their architectural roles, not unverified operational health.
- Open WebUI personal-memory replication — SHOULD BE DELETED
Single change: stop the separate personal-memory sync and make any retained alternate chat surface use the same authorised read path.
Cost: half a working day to identify dependencies and verify suppression behaviour.
Keep Open WebUI only if you actually use its distinct interface. The dossier supplies no reason for another personal-memory copy.
- Skills library — ONE CHANGE AWAY
Single change: make current authority explicit in triggers and procedures, and retire procedures whose subject has been retired.
Cost: roughly half to one working day for a targeted pass.
The number 108 is not itself a defect: skills load on demand. I would not undertake another whole-library overhaul based on a count or a name list. Fix stale task-writing and memory-consolidation guidance first.
- Conversation store — SAME
A transcript database is the right home for conversations and provenance. Size alone is not a reason to migrate it.
Set retention deliberately and test lookup/restore. Do not prune original sources while retained facts depend on them.
- Application/container estate — ONE CHANGE AWAY
Single change: give every running service a named user-facing purpose, data owner and retirement decision.
Cost: half a working day for the inventory and rulings; actual retirements depend on what it finds.
Forty-eight containers are not forty-eight products. I would not delete services from a container count. Equally, “nothing obviously orphaned” is not sufficient justification to keep them.
-
The five changes I would do first
-
Finish and enforce task authority
Cost: half to one working day.
This prevents the most consequential regression: frozen Markdown being treated as current because it looks fuller, while some processes still read or write it.
Acceptance: one real task edit and one completion agree across app, digest, evening close, wall display and every retained export. Legacy files cannot accept operational writes. Deleted exports either regenerate correctly or have no consumers.
- Remove automatic personal-memory injection
Cost: 2–4 hours, subject to the existing admitted-release boundary.
The failure is observed, its agreed remedy already exists, and it contaminates unrelated questions. This is a better return than repairing vectors first.
Acceptance: fresh mortgage, deadline and file conversations receive no SIPP-fee prefetch. Explicit personal-history queries still follow their authorised route. Joe performs any required gateway restart.
- Retire scheduled speculative drafts and periodic model triage
Cost: roughly half a working day.
This removes recurring judgement you did not need, reduces noise and eliminates scheduled model consumption without sacrificing failure detection.
Acceptance: the schedules are retired, the deterministic failure packet still identifies and escalates a real test incident, and foreground drafting still works.
- Add verified commitment receipts and reconcile consequential dates
Cost: half to one working day.
This closes the gap between a useful conversation and dependable action. It also tests whether the quiet calendar is genuinely quiet rather than incomplete.
Acceptance: five real commitments reach verified records without a second prompt; tentative remarks create no obligations; the Virgin window and Google cancellation sequence have sourced dispositions. No artificial due dates are added to DIY backlog.
- Prove one recovery, then apply bounded retention
Cost: 1–2 working days.
This addresses the failure you cannot reason your way out of after the host is gone. Restore the task store and its application, notes, source dependencies and latest privacy state in isolation. Then remove caches and expired snapshots from the backup scope.
Acceptance: a post-cutover task edit survives recovery, forgotten material remains withheld, and the recovery instructions are reachable without the failed VM.
I would not begin with file moves, a new memory provider, another dashboard or a wholesale reduction to ten cron entries. Your central design is already closer to right than the size of the estate suggests. The largest remaining gap is that declared ownership is not yet consistently enforced—and some of the cleanup has actively contradicted it.