Household Operations Platform

The Services Desk at https://sol.system42.one/services/desk/ is the private control surface for IT and household operations. It uses the existing owner/admin-token boundary and extends the ticket system with generic work items rather than creating a separate household application.

Operational model

Priority changes can affect several independent surfaces: the Owner brief,
sanitized staff brief, operating schedule, and dated sale-preparation banner.
Use the sale-preparation update procedure
to reconcile them and verify the visible banner and any affected TV feed.
The current recap controls and generation behavior are documented in the
Services Desk README; keep its public mirror
synchronized when those controls change.

The display fleet capture waits for a visible sale-preparation timeline, its
current-time marker, and the household clock before publishing a frame. A fixed
delay can capture the older command brief while authenticated API reads are
still finishing. On a readiness timeout, retain the previous frame and report
the capture failure. Verify fresh timeline geometry and an actual HLS frame
after recovery; service activity alone does not establish visible content.

- Work-item domains: IT, household, staff, property/sale, inventory, administrative, and recurring non-medical care.
- Shared work-item fields: owner, priority, status, due date, location, notes, dependencies, attachments, recurrence, visibility, explicit staff assignees, staff activity, and audit timestamps.
- Candidate/staff profiles: explicit profile kind and lifecycle, role,
engagement status, hours, availability, rate, permitted and prohibited duties,
onboarding checklist, notes, source links, and provenance-labeled claims.
Conflicting source values coexist and are shown as discrepancies.
- External contact profiles: private non-staff associates, relationship type,
organization/role, contact preferences, summary, notes, provenance, last
contact, next follow-up, tags, project links, work counts, and interaction
counts. A profile does not grant a credential.
- Projects: lightweight contexts connecting external contacts, work,
inventory, dates, location, tags, and history without creating a second task
hierarchy. Project lifecycle, external dependencies, and evidence-state
records remain independent from work-item completion.
- Housing search: the private North Richland Hills search is one projects
record with versioned candidate state, linked work_items, explicit listing
dependencies, evidence, and timeline history. Marlette Court is the current
geographic anchor; component scores remain visible and manually ranked rather
than collapsed into an opaque total.
- Inventory items: immutable human-readable container/item ID, project,
owner, origin/current/destination location, contents, attachment references,
packing state, disposition, handling flags, notes, and linked work.
- Time entries: actor, linked staff record, work/IT/general source, server timestamps, elapsed seconds, snapshotted cents-per-hour, estimated pay, status, method, and audit attribution.
- Timeline: a chronological stream for staff communications, work changes, and automated events.
- Strategic state: command brief, August 18-28 schedule, workstreams, protocols, staffing plan, and handoffs.

The Worker implementation lives in random/services-platform/src/index.js; D1 migrations are in random/services-platform/migrations/; and the desk client is random/www/services/desk/index.html.

Care.com boundary

There is no supported Care.com consumer API in use. The integration does not automate Care.com pages, reuse browser cookies, call private endpoints, or scrape profiles and conversations. This boundary follows the current Care.com terms at https://www.care.com/about/terms-of-use/.

Permitted inputs are:

• Care.com transactional notifications delivered to David's own mailbox.
• Screenshots, notes, PDFs, and other records deliberately supplied by David.
• An official personal-data access copy requested under https://www.care.com/about/privacy-policy/.
• Manual corrections and updates made through the private desk.

The four current candidate dossiers retain only facts from supplied profile
snapshots, applications, notification excerpts, Owner notes, and direct
communications, each with provenance and capture time. Conflicting experience,
rate, availability, and service claims remain separate rather than being
silently resolved. Detailed background-check contents are not stored in the
general operations record.

Email event flow

service-request-mailwatch.service runs /home/david/random/bin/service_request_mailwatch.py every 60 seconds. The watcher reads the local Solmail SQLite cache and recognizes a narrow set of Care.com notification subjects: new message, application, and interview confirmation. It extracts notification-level metadata and a bounded excerpt, then:

1. Writes an idempotent event to the D1 household timeline.
2. Sends an XFCE desktop notification with notify-send.
3. Queues a private Unified Clock web push.
4. Adds the event to custom notifier history.

Delivery state for each destination is recorded in ~/.local/state/service_request_mailwatch/watch.db; failed destinations retry independently.

BlueBubbles event flow

The existing allowlisted BlueBubbles new-message webhook continues to feed
the explicit custom-notifier reply prompt. It also applies a narrow private
operations classifier for known staff/property contacts and specific
household-staff, sale, county-tax, appraisal, homestead, and foreclosure terms.
Unrelated messages remain outside the Services Desk timeline.

Relevant messages enter a mode-0600 SQLite ledger before delivery. D1 timeline,
Unified Clock private push, and custom-notifier history each have independent
completion state and retries. The event ID is a stable hash of the message GUID;
the raw message/chat GUID, phone number, email address, and BlueBubbles server
credential are never sent to D1 or push. The source is BlueBubbles webhook via
Mac Mini and completeness is complete, unlike truncated Care email excerpts.
Staff Guest cannot call the external-event route or read the private timeline.
Schedule rows likewise require explicit staff or public visibility; an
assigned row is returned only to the linked staff profile. Unmarked legacy
schedule data remains private.

Operations

bash
systemctl --user status service-request-mailwatch.service
journalctl --user -u service-request-mailwatch.service -n 100 --no-pager
python3 -m py_compile /home/david/random/bin/service_request_mailwatch.py
cd /home/david/random/services-platform && npm run check

The private APIs are under /api/service-requests/admin/:

• operations
• work-items and work-items/:id
• time-entries and time-entries/:id
• staff and staff/:id
• timeline
• operations/events
• operations/external-events
• contacts, contacts/:id, and contacts/:id/interactions
• projects and projects/:id
• inventory and inventory/:id
• search?q=...
• display-session

All require a valid named Services Desk credential or the recovery Owner
credential. Do not put the token in documentation, logs, notification bodies,
or command arguments.

Automatic command brief

sol37-household-brief-inference.service runs
scripts/household_operations_inference.py against the live private APIs. The
inference input is the current project, dependency, candidate, work-item, and
timeline state. A stable source hash prevents unnecessary writes, while
expectedRevision optimistic concurrency prevents a stale model result from
overwriting a newer Owner edit. A brief whose inference metadata has
manualOverride: true is authoritative and the background reconciler skips it
until an Owner explicitly clears that flag. Declined/completed conversations stay closed;
proposed schedules and trials remain proposals; candidate contact never becomes
employment. If the local model returns unusable output, deterministic fallback
rules still refresh the phase, dependencies, newest Care application, candidate
count, and next action. The dashboard refreshes the authoritative state every
60 seconds only while visible, idle, and outside an active edit.

Automatic candidate intake

Care.com remains a notification-email integration, not conversation scraping.
When service_request_mailwatch.py observes a supported
application_received email, it posts the normalized partial event to the
Worker. The Worker idempotently creates a provisional candidate profile,
source/claim records, and a private screening work item. It does not create
active staff, assignments, credentials, shifts, trials, schedules, or payroll
liability.

Browser and screen display

The default desk theme is dark. The shared header provides three presentation
controls: theme, cards, and display mode. ?display=1 forces the compact header
on desktop, tablet, and phone and shows the same two cards in any authenticated
browser: a generic Staff Guest View QR and a live SOL Vision frame. Ordinary
LAN browsers and the Mac use the same-origin image route through a one-second
fetch-to-blob loop. The QR is
issued through the Owner/Operator-only display-session route as a one-day,
rotated preview_guest; it is not linked to a candidate and cannot confer
employment. The Vision frame preserves the full 240x324 source at 20/27.
Hide/show affects both cards. Pointer activity fades them and pauses refresh;
eight idle seconds restores both.

The Mac Mini loads this page directly. Record Player receives an HLS rendering
of the same interface; its compositor overlays matching independent live QR and
Vision inputs after removing the page copies from the base frame. Lee's TV is
denylisted. The current fleet scope is mac-record-player.

The Living Room TV uses its existing persistent DashCast service and opens the
private Housing panel with the housing-tv presentation query. That mode shows
the same D1-backed records in a large 16:9 six-card layout and defaults the two
floating display cards hidden. It does not alter Lee's TV, Record Player,
Kitchen, Mac, or the central fleet mode.

North Richland Hills housing workstream

Migration 0017_nrh_housing_search.sql establishes the private
nrh-housing-search project with active_search lifecycle, the Marlette Court
anchor, six candidate configurations, 11 visible 0-5 scoring dimensions,
manual rank overrides, working rents, dated freshness observations, full
listing links, accessibility notes, and archive-preserving candidate states.
Migration 0018_nrh_housing_owner_status_and_asymmetric_pairs.sql revises those
records into six strategy cards, adds right_sized_unit_distribution as the
twelfth component score, records the roughly $4,000 target and $5,000 outer
ceiling, and permits a modest 1-2 bedroom mother-side unit to rank above a
superficially symmetric pair. Availability observations retain their source.
Direct owner or realtor confirmation outranks listing metadata: 6300 Mark is
confirmed available, while 6302 is leased / watching and contributes no
actionable combined rent.
The Housing panel is available only to Owner and Operator. It supports updates
to rank, state, rent, listing URL, verification summary, freshness note, and
last-checked time through the existing Worker-mediated project PATCH path.

Canonical work items also track Brenda's reported-sent property email with the
explicit waiting_for_email status, import and comparison rather than blind
replacement, April Court direct checks, asymmetric pair generation, the 6300
recheck, and the 6302 tenant-move watch. Mark Court's 6302 Mark Ct #6300 label
is retained exactly as observed. Unavailable or leased listings move to an
explicit state and remain in project history; they are not deleted.

Assignment, schedule, and routine rules

- Owner and Operator use the Work board's explicit save to create or edit a
task and its assignment together.
- Assigned work must use staff or public visibility; the Worker rejects a
private assigned item even if a browser control is bypassed.
- The editable operating schedule is strategic state. Scheduled tasks and
routines are derived from work-item due times and recurrence so assignment
and routine state cannot drift into a second task database.
- Recurrence supports daily, weekly, or monthly frequency, a positive
interval, weekly weekday selection, and an optional end date. It requires a
first due time and the end cannot precede the first due date.
- A work item may also carry a project, subtype, independent follow-up time,
decision-required flag, external-contact links, inventory links, and a
deliberately sanitized Staff Guest handoff.

People and relationship rules

- Household staff and external associates are different objects. Do not put a
realtor, prospective buyer, title professional, vendor, or contractor into
staff_profiles merely to make them searchable.
- Candidate is not staff. applied, contacted, screening,
interview_requested, interview_scheduled, trial_proposed, and
trial_scheduled are candidate lifecycle states, not employment. Only the
Owner-only explicit hire action may change a candidate to staff, hired,
and active. Ordinary profile edits cannot cross that boundary.
- Current relationship map: David is Owner/decision authority; Isis G., Lisa M.,
Norma N., and Jeanne M. are candidate records and nobody has been hired.
Isis remains unanswered, Lisa declined the eventual part-time structure and
that conversation is closed, Norma is contacted and awaiting a response, and
Jeanne remains available for later screening. Brenda Sarmiento is the
seller's realtor; Ashley Haile is the primary prospective buyer whose August
19 walkthrough is complete and whose written offer is pending through Brenda.
- The active Deer Valley Sale & Move project groups sale readiness, buyer and
realtor coordination, Tarrant County tax resolution, packing, storage, and
move continuity.
- Contact data is private by default. The Worker returns HTTP 403 to Staff
Guest for contacts, projects, inventory collections, and cross-model search.
A staff-visible task can expose only an explicit handoff such as "buyer visit
at 2 PM", never a private contact profile.
- Record interaction appends a provenance-labeled contact event and optional
follow-up. It does not transmit email, text, Care.com, or other messages.
- State transitions are explicit. Reported is not confirmed, proposed is not
agreed, scheduled is not completed, and candidate is not staff. Unknown offer
terms remain null until a source document establishes them.

Candidate claims and fairness

- Candidate facts are linked to profile snapshots, application text, platform
notifications, direct messages, Owner outreach, or scheduling events.
- Structured profile and narrative claims remain separate. For example,
10 years profile and 15+ years narrative coexist with a source discrepancy
badge rather than becoming a false verified total.
- Candidate credentials begin provisional. They do not create shifts,
assignments, payroll liability, active-employee metrics, or proof of hire.
- Do not score or rank candidates from photos or protected or irrelevant
personal characteristics. Any priority must be explicitly user-entered or
transparently based only on role-relevant capabilities.

Deer Valley sale, tax, and evidence state

- Current sale lifecycle is awaiting_offer: the August 19 walkthrough
completed successfully, Ashley told Brenda an offer will follow, and Brenda
will prepare a seller net sheet after receiving it. No price, earnest money,
option, inspection, closing, concession, possession, title, or acceptance
term is currently confirmed.
- Parker County taxes are paid. The separate Tarrant/Azle ISD matter remains in
Linebarger correspondence with an approximate August balance of $48,686.
David's possible $5,000 initial payment is a proposal, not an agreement.
- Homestead evidence stages remain distinct: prepared, delivered, received,
accepted, granted, and account adjusted. A recovered 2019 Form 50-114 was sent
to Parker CAD; PCAD review is pending and retroactivity is not inferred.
- Pending project dependencies currently include Ashley's written offer,
Brenda's offer forwarding and net sheet, PCAD's review, Linebarger's written
response, Norma's response to the broader role and conditional hours, and
Isis's unanswered historical follow-up. Lisa's conversation is resolved and
must not reappear as an active dependency without a new Owner decision.

Inventory and preserve-first rules

- Inventory is the thing/container; work is the action involving it.
- Every inventory record needs a printed human-readable ID such as
LAB-BOX-001. A future QR may point to that record but cannot be its only
identifier.
- The initial inventory collection is deliberately empty. Create a record only
after observing a real item or container.
- Unknown ownership or disposition defaults to REVIEW. Never infer disposal
from an unidentified item. DISPOSE_APPROVED must be explicit.
- Staff handling sequence remains photograph, classify, consolidate,
document, containerize, label, record location, then obtain any required
owner decision.
- Decision-required or waiting-owner work is not failure; preserve the current
state, continue elsewhere when safe, and record the decision when made.

Time clock

- Owner may clock self against a work item, IT request, or general activity;
inspect all entries; record missed time; and correct or void entries.
- Staff Guest may start and stop only its own timer and only for a work item
explicitly assigned to the linked hired, active staff profile with an active
credential. A provisional candidate guest cannot use the time clock.
- Staff Guest cannot submit general/IT time, change its rate, create manual
entries, correct/void time, or read another actor's ledger.
- Only one active entry is permitted per actor. Active duration and estimated
pay update in the browser, but final seconds and cents are computed by the
Worker.
- Rate cents are copied into the entry so later staff-profile rate changes do
not rewrite older estimates. A void remains in the audit ledger and counts
as zero.
- Estimated pay is operational planning only; this is not a payroll, tax,
overtime, break, approval, or statutory recordkeeping system.

Help and tutorial

Every authenticated desk role has a Help dialog and replayable guided tour.
The tour opens the real role-permitted panels, highlights the live UI, supports
Back/Next and keyboard navigation, and adapts to mobile. First-run completion
is stored only in browser localStorage. Staff Guest help must not mention or
spotlight IT, private timeline, credential, personnel-editing, manual-time, or
time-correction controls.

Appointment reminder data and rendering

Private medical schedule rows may include three concise reminderLines for the
orb display. Keep arrival and start times distinct; a missing time displays as
TIME TBD. A tentative medical visit remains a timeline node with its tentative
status visible. Reconcile the orb snapshot after changing the canonical schedule
using services-platform/scripts/reconcile_nest_appointments.py.

The September 23, 2026 storage workaround places only the generated orb video in
/home/david/.cache/sol-orb-clock/, selected by the orb service's
render-cache.conf drop-in. The original LAN media path is a symlink to that
bounded cache. Restore the normal data-drive render path only after adequate
space is available; preserve the playback URL and verify receiver progress.