The Record Tabs

The allowance, the quote and the line items. decision_allowances is a real table, unique on (project_id, decision_id), and quote_line_items and quote_line_item_decisions ship with it. Category budgets are a JSON string in projects.category_budgets, added by migration 0005.

The middle card. Nothing about money is scoped to a room today. An allowance hangs off a decision, a quote line has a category and no zone, and the budget categories are a JSON blob rather than a table. Every figure in "What each room has left" is derived, not read.

The derivation itself needs no migration: decision_zones already joins a decision to its spaces. What it needs is a product answer. A line item tagged to decisions in three different rooms has to land somewhere, and the weight column at 0014:74 is nullable and its own comment calls it unused. The rollup at strategies.go:297 divides evenly, which is a placeholder rather than an answer.

The first card is always present for an owner and opens /house/people/seats. With one owner it is where an invitation starts; with more it expands into the responsibility overview. Household members are not mixed with builders and trades because seats and contacts carry different meanings.

contacts, contact_projects, contact_zones and contact_systems sync for the delivered directory. Active seats and member_tags sync for the delivered household drill. The builder is identified by the builder seat, never guessed from contacts; the person's optional phone is projected through that seat, and the call action is absent when no number was supplied.

Project-scoped Room and System assignments supply the scope shown under each name and the routing list. Within an axis, any selected value matches; when both axes are present, both must match. A contact with no assigned scope still appears in the directory but not in routing.

0041_drawing_reader_p5.sql gives drawing_sets a selected immutable extraction run and gives sheets their number, title, discipline, revision and stated scale. DrawingsScreen reads the API-backed set and sheet projections at /house/plans; no sheet row or storage credential is synced to the phone.

P6 can answer a question such as "where is the kitchen?" from retained spaces and cite the exact sheet region. P7 now writes sheet_zones through the explicit owner-only preview/apply decision; P8 still owns replacement when a later revision is selected.

The screen groups by the explicit discipline returned by the selected P5 run. It does not infer discipline from the sheet number, and a read failure never becomes a calm empty filing cabinet.

Range hood filter degrease and Fall gutter cleaning are authored rows in data/library/content/maintenance.json. The rebuild has a minimal maintenance_tasks placeholder today. Y4 adds the imported catalog, project schedule, completion ledger and reversal ledger; the client never invents the next date.

Catalog definitions receive authored room-archetype relationships, and materialization creates one task per matching classified project zone. A manually added zone with only a label receives no inferred archetype and no room-scoped Care work until it is explicitly classified.

House-level work uses The house itself. Definitions that depend on a water softener, radon system, garage door or another unrecorded property feature remain inactive until the later property inventory exists. Empty applicability is never used to show equipment work confidently to every house.

The file, and only the file. project_documents carries file_id, file_name, mime_type, uploaded_by, uploaded_at, document_type, an extraction status and supersedes_document_id (0001_init.sql:1373-1394). Upload, storage, supersession and the extraction pipeline all work.

Every field on every row above. A permit number, an issuing authority, an issue date, an expiry, an inspection state and whose move it is are six values and the table has none of them — uploaded_at is when somebody put the PDF in, which is a different date and never the one a permit turns on. And a paper cannot be uploaded in the first place: knownDocumentTypes is a closed set of seven and all seven are plan drawings (documents.go:92-101), so a permit, a contract and a certificate are all refused at the handler.

Waiting first, live second, signed third. The obvious tab is a file list newest-first, which is a folder with a search box — the reason to open this door is almost always is the thing that is holding us up still holding us up, and that question has one answer at the top or it has none. The lead card is the only one that ever changes.

A drawing at a quarter inch to the foot needs every pixel it can get, so the sheet takes the whole width and everything else is one line under it. What that line carries is the thing a person standing in a half-built house actually needs: which revision this is and who sent it, because the argument on site is almost always that somebody is holding an older sheet.

You opened A-1 from a list of nine, so swiping moves through those nine. A viewer that returned you to the list between every sheet would be making you re-answer a question you already answered, and comparing the floor plan against the elevation is most of why anybody opens these at all.

This strip carried a second ghost CTA until Q150 ruled on it. A sheet leaving as a file hands somebody's plan set to the operating system, where seat removal, archive and account deletion cannot reach it; a sheet leaving as a link is a sixth links.type and a subject column the table has no analog for, on behalf of an affordance the frame's own argument never makes. That argument is about the builder's signal, not about handing a sheet to a third party, so the control is removed rather than left standing as a promise.

It is there because a job site has no signal and a builder asking to see something does not care whose app it is in. The offline rule on 00 says what still works rather than what broke; this is the same idea one step earlier, letting somebody take the thing with them before the signal goes.

AE1 shipped it into a drift table, app-private, so seat removal and account deletion reach it and an archive deliberately does not. Once a sheet is kept the strip says so and offers the release instead — a hold somebody chose needs a way out that is not deleting the app, and 26 frame 4’s “no way to clear this” is about the cache the phone manages rather than about this. It also reads the kept copy when there is no signal, and says out loud that it is not a fresh read: the argument on site is almost always about which revision somebody is holding, and a stored sheet drawn silently would be this app joining that argument on the wrong side. Q238 is the ruling.

The opened revision is the first object on the screen. A candidate set can be asked only after the user deliberately opens it, and every later turn inherits this visible boundary.

This conversation lives inside Plans & drawings. It does not follow the user around the app or compete with the three-door dock.

The question stays in the transcript while HouseChalk works. The four lines are stages the system owns, with no fake percentage, denominator or spinner.

The source follows the claim in reading order and opens the evidence region. A follow-up keeps the same revision unless the user deliberately starts from another set.

The model is allowed to say less than the question hoped for. The boundary on scale-derived measurements is visible before somebody carries the answer onto the job site.

The region exists because the answer cited it. It does not turn the viewer into an annotation tool, and leaving the question clears the layer.

Frame 6 on the record-tabs page already settled the sheet-first composition. P6 adds evidence to that screen rather than creating a second drawing viewer.

The answer names what this revision does not contain, then keeps the conversation open. It does not say the house has no floor finish or recommend one.

This is the product rule P6 exists to enforce. A calm empty state here would turn one failed read into a claim about the house.

The old question remains anchored to the incomplete run. This panel follows the new P5 run instead of pretending the blocked answer can become complete by refreshing.

Retry A-2 only retries the sheet. HouseChalk waits for an explicit re-ask before it spends another question call.

Ask again creates a linked question against the recovered run. The previous blocked turn remains visible, and the new paid call is deliberate.

A failed job is not an empty answer and not a reason to clear the field. The user can retry the exact request or leave it and ask something else.

The call may incur cost. Nothing silently repeats it just because a screen remained open.

The failed question is immutable. Try again creates a linked request against the same retained run instead of resetting the failed row to queued.

The repeated person bubble records the deliberate action. HouseChalk never silently resubmits a failed provider call.

The seven clear matches are summarized, not confirmed one at a time. The review exists only because two proposals fell below the configured threshold or were ambiguous.

Starting review does not create a zone, a sheet link or a decision. The owner sees one complete preview before the canonical apply.

The live screen opens with both choices unselected. This frame shows the result of the owner's tap so the selection treatment is visible; Continue stays unavailable until a choice is made.

The immutable drawing space remains Office. The chosen library room type controls valid decision seeding without rewriting what the sheet says.

The position marker is honest because the review count is known before the owner begins. A third prompt cannot appear halfway through this run.

The proposal's retained candidates supply the room types. Neither of these opens a free-form taxonomy picker; the quiet escape handles a genuinely different room.

Every proposed space is present before apply, not just the uncertain ones. The owner can trace every row back to its sheet and see which two classifications came from them.

Add nine spaces creates the canonical zones, their sheet links and the valid decision set as one owner-authorized operation. Back edits retained choices; closing leaves the proposal untouched.

The success screen names what changed and offers the two places the owner is likely to go. It does not repeat all nine rows after the transaction has already committed.

The canonical spaces keep their Rev 3 proposal and sheet evidence behind them. P8 can later compare a new revision without pretending these were entered manually.

The non-owner can inspect the retained result but cannot submit review decisions or discover an apply endpoint through disabled controls. The action is absent because the permission is absent.

Sam is the project owner in the pinned fiction. Naming the person who can move this is more useful than a generic permission error.

A partial apply would be worse than a visible failure: spaces, sheet links and valid decisions commit together. The error therefore reports an unchanged house record, not a fraction.

The immutable proposal and the owner's two review choices remain available. Retry repeats the apply operation, not the questions.

The run completed, but zero proposals cannot become a successful binder update. This state has no primary action and creates no durable apply command.

Rev 3 remains readable in Plans & drawings. The copy names the narrow absence: this retained run produced no space list to review.

Opening Rev 4 still lets the owner read and ask it. The only new action is Compare; the current marker stays on Rev 3 until an explicit adoption transaction commits.

This is still the Plans & drawings tab. The dock disappears only after the owner enters the bounded comparison and decision flow.

Sheet pixels are evidence, not the decision. The owner sees matched, changed, added and absent rooms after the retained runs have been compared.

Garage is absent from Rev 4 but already carries human work. The comparison says it will survive before asking what to do with rooms and decisions that have no choices, answers, notes or files.

Update makes Rev 4 current and changes only rooms and decisions with no human work. Remove makes Rev 4 current but adds none of its rooms or decisions. Keep leaves Rev 3 current and returns to Plans without a confirmation screen.

Protection is not a fourth option and not a per-room burden. The server finds choices, answers, notes, files and other human work, rechecks them under lock, and keeps them in all three paths.

The preview names additions, replacements, protected exceptions and retained history. The button repeats both adoption and treatment; generic Confirm would hide the consequence.

The preview token covers the comparison and the rooms and decisions with human work. New work invalidates it, so the transaction cannot remove something a person changed while the preview was open.

The action removes only rooms and decisions HouseChalk created from Rev 3 that still have no human work. It does not remove plan sets, evidence, questions or anything a person changed.

The preview explicitly says the two Rev 4 rooms stay in Plans & drawings. Otherwise Remove could look like a temporary step before the new plan silently adds them again.

The owner sees not only what changed but that Garage survived. “Everything updated” would be shorter and false.

Rev 4 becomes active and Rev 3 points forward to it, but the prior set, selected run, evidence and applications remain readable provenance.

Human work remains in the binder, so the result names both what was removed and what stayed. The owner is never shown a false blank-slate claim.

Rev 4 becomes the active source for viewing and questions even though the owner declined to seed canonical rooms or decisions from it.

Activation, supersession and canonical treatment commit together. The error can promise Rev 3 stayed current because no partial state is permitted.

The treatment and preview remain durable enough to retry, but any stale protection fingerprint returns to comparison rather than forcing the old preview through.

The implementation reuses a deterministic command key derived from the candidate, treatment and preview token, so route disposal or restart cannot create a second command.

An explicit server rollback still uses frame 32. Only a network failure, unreadable response or lost response uses frame 33; this state makes no claim that the request succeeded, rolled back or changed the current set.

The sort from frame 5 does not move: waiting permits, live permits, then ordinary papers. The action follows the record instead of replacing it.

On a phone, Add a paper opens the platform file picker immediately. Cancel returns here without creating a route, upload or document.

Owners and builders see the action. A viewer sees the same synced record without an inert or disabled upload control.

Contracts, change orders, plans and inspections remain owned by their source flows. Y3 joins inspections to their permits. Y9 brings the other source read models into this tab; this intake never duplicates them as binder documents.

Only this bordered surface accepts a drop. Clicking it opens the same picker. The rest of Papers remains ordinary navigation.

The flow accepts one paper at a time because the next fields belong to that file. Batch selection would create an unlabeled queue and make a permit type easy to attach to the wrong upload.

Paper type opens a bottom sheet on compact and an anchored menu on wide. The first set is Permit, Certificate and Other paper. Plans, contracts and change orders stay in their own flows.

The existing upload-session lifecycle retains the bytes. Restart keeps only the pending session id and expiry. The app asks for fresh signed PUT details and creates a new OPFS object URL for each web attempt; neither enters Drift. The document writer accepts only a completed upload from this project, and the upload id never reaches sync.

An interrupted upload remains Waiting to upload and retries with the same local task. Papers gains no document row until both upload completion and the idempotent document write succeed.

A permit can be saved with a label and application date before it has a number or issue date. Empty means not issued yet; it does not mean the record failed to load.

Application, issue and expiration dates use the platform calendar control. If entered, application cannot follow issue, and issue cannot follow expiration. The field always prints the localized date rather than storing formatted copy.

The name explains who is following up on the permit. It does not create a task, notify that person or claim they accepted responsibility.

If the permit write fails, the completed upload and entered facts remain on this screen. Retry sends the same idempotency key, so it cannot create a second document or permit.

Every project seat may ask to open an accessible document. The gateway authorizes the document, issues a short-lived storage URL and marks the response private and no-store. The URL, signed headers, storage key and completed upload id never enter Drift. Only the pending upload session id and expiry survive a restart.

The action carries the observed due date, 18 September 2028. A second device that has already advanced this task receives the changed-task state instead of appending another completion.

The 18 June entry carries its Kitchen identity and label snapshot. Renaming, reclassifying or deleting the room cannot rewrite where the work was done.

The sheet focuses this heading on entry, traps focus, reads Close then the two actions, and returns focus to the task row when dismissed. Only an owner or builder in a writable project sees completion actions.

The mockup draws the HouseChalk field that opens it, not a custom calendar. Compact and desktop use the same date bounds and localized result.

The client permits a local date through today. The server also requires the date to be on or after closing and no earlier than the latest effective completion for this task.

The queued assertion stores this date-only value and the observed scheduled due date. It does not replace the payload with a later retry date.

Set closing date is online-only, carries the observed project version, and reconciles the imported catalog in the same locked project transaction.

This state does not draw future chores or a caught-up card. Without a closing date, the system does not know when any interval begins.

The action opens the themed platform calendar, announces the selected date, and returns focus here when the calendar closes.

A builder can complete Care work after closing, but cannot author the project's closing date. A viewer can only read. Neither seat sees an unavailable Set closing date button.

The explanation does not change by role. Only the action changes, and absence of authority is expressed by absence of the control.

On 18 September 2028, fall runs through 30 November 2028. This alternate state assumes the September and October work is complete; the December task remains reachable under Later.

This is the existing year-two settled pattern — a tick and a sentence on the outline rung, where a sage card used to say it. It reports a useful result and never appears when the canonical query failed.

The local overlay moves the row into Already done, but the server still owns next_due_on. Sync clears the overlay only after both the completion and updated task arrive.

If delivery never started, Undo removes the local assertion. Once an attempt begins, Undo queues a dependent reversal and first replays the original idempotency key to recover the canonical completion id.

Sign-out or account switch blocks this drain before credentials change. Another person or another seat can never send Sam's queued assertion.

The Care view model keeps loading, data and error separate. It never tells someone their house is caught up because the read failed.

The spoken state announces once. Try again is a real action, and retry does not move focus into an empty schedule while the read is unresolved.

Transport and retryable server failures preserve the date, occurrence and idempotency key. Retry sends the same assertion instead of minting a second completion.

An authorization failure removes the overlay and refreshes membership. An invalid date returns to date selection. A stale occurrence uses frame 45 and is never retried as the old occurrence.

The server locked the task and rejected the old observed due date without appending history. Sync then supplied the canonical December occurrence.

The optimistic overlay is gone. The changed state announces once without stealing focus, and the reader must open the refreshed task before acting again.

projectWritePosture removes completion, reversal and closing-date actions while the project is read-only or its posture is unknown.

Restore resumes only the originating principal's drain. The state announcement does not steal focus, and there is no Retry button while archive still blocks the command.

The save carries If-Match for the observed project update and one idempotency key. The project update and Care reconciliation share one project lock and transaction.

Untouched tasks re-anchor. Recurring work with history stays derived from its latest effective completion, completed one-time work remains retired, and no historical room or completion snapshot changes.

Clearing is offered only while no completion exists. It retires catalog tasks as care not started instead of deleting synced rows.

The fiction's earliest completion is 18 June 2027. The server rejects 22 June with closing_after_care_history before it can make that completion precede closing.

The field keeps the rejected selection visible, explains the valid boundary in the reader's terms, and returns focus to date selection.

care_history_exists leaves the closing date, schedule and append-only ledger untouched. The only available next act is a valid correction.

The conflict is announced once, preserves keyboard focus, and contains no disabled Remove action.

This state appears only after the completion row and updated task arrive from the server. The pending overlay in frame 42 has cleared.

17 December comes from the canonical fold over the completed 18 September occurrence. The device never adds 90 days itself.

The action carries the completion id and opens the reversed-history state. It appends a reversal; it never deletes the completion.

The 18 September completion remains visible with its room snapshot and a linked reversal fact. The record does not pretend the first action never happened.

The same scheduled occurrence is active again because its completion no longer participates in the effective fold.

Only the seat that created the completion may reverse it during the allowed Undo window. A second reversal is refused rather than treated as success.