# 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](sale-prep-transition.md#priority-updates-and-verification) 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](../services-platform/README.md); 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.