Seventy-Three Questions: The P4 Build, Read Aloud With Its Defaults

One Word Is a Valid Answer

You can answer this entire episode with one word. That word is defaults. Every question you are about to hear is an assumption the P4 build would otherwise make quietly, without asking you, and each one comes with the answer the plan already assumes if you say nothing. So this is not homework. It is a list of places where you might disagree, read slowly enough that you can notice when you do.

The questions come from a sweep on October 11. Six readers and a critic compared the locked card rounds log against the old handoff, the Cohort B spec, the code, the iPhone app, the producers and the docs. Three drafters wrote the questions and three adversarial verifiers tried to break them. Things the log already rules are not asked. Answer by number, and the ruling moves into the plan files and the question disappears.

There are 8 blocks. A, the data behind the new words. B, the inbox leg. C, system cards and the producer contract. D, repo routing. E, Stash, search and bulk. F, leftovers from the old plan. G, the iPhone app. And H, housekeeping. Block A blocks both Leg A and Leg B, so if you only have energy for one block, make it that one.

Block A: The Data Behind the New Words

Question 1, Pärl and OneDay data. The proposal is that Pärl means today's rows with nature set to remember, and OneDay means today's rows with nature set to spark, which is exactly the split the Library already uses. There is no side effect on horizon. Today the capture skill's oneday verb also sets horizon to someday, and that goes away. The log names Pärl and OneDay but never ruled the mapping. Default: yes.

Question 2, the Stash chips and decision D-01. The Stash card shows and edits five things: category, when, weight, tags and audience. Some of those are axes that D-01 struck. Do you want a formal add-back, meaning first-class columns on captures, a dated amendment to D-01, and a schema change? Or a legacy display that reads from the compatibility sidecar and stays until you say a chip is unused? Default: legacy display.

Question 3, counts with one meaning each. The bell shows all open system messages. The N-plus on the pinned card shows system messages not shown in the flow. The end mark, that's all N, counts your own cards only, no system cards and no deck. And the Inbox badge in the nav shows the same N as the end mark. Four counts, four meanings, no overlap. Default: yes to all four.

Question 4, a category data fix. Rewrite parception, spelled without the umlaut, which has 2 open items, into pärception with the umlaut. And move the lone infra item to pärkit. This rewrites your own labels, it runs once, and the list of ids touched is logged. Default: yes, both.

Question 5, the Done view. It shows every done item regardless of which line it came from, inbox, Stash, Pärl or OneDay, newest first. Default: yes.

Block B: The Inbox Leg

Question 6, what the bell opens. Today it opens the inbox filtered to the system category, and that filter is something the new frame removes. Three options. Scroll to the first system card now. Open the system all-page when it exists, though that page is not designed yet. Or open the legacy Wall. Default: scroll now, and switch to the all-page later.

Question 7, the page heading. Does the inbox, and likewise Stash, Pärl and OneDay, keep a big Inbox heading at the top? Or does the underlined word in the nav replace it? Default: no heading. The underlined nav word is enough.

Question 8, the app switcher on the phone. Time, Director and Stats need a home on the two-line phone nav. Line 1 beside the brand, line 2, or desktop only. Default: line 1, to the right of the brand, before the plus button.

Question 9, the Momentum percentage bar. The pink bar inside M1 stays, even though its tag editor is legacy and new captures carry no tags, so the number will slowly decay toward zero. Keep it or not? Default: keep. M1 is today's content, tidied, not redesigned.

Question 10, the composer's Save button versus its Repo button. Save runs the automatic path, meaning the voice intent call and the bracket rule. A Repo body on the plain path runs none of that. Should the automatic path honour an explicit routing tag, so the two buttons behave the same? Default: yes.

Question 11, resurfaced postpones. When a postponed item comes back to the inbox, it arrives raw. Should the locked card mark it, the way today's UI says from the past with an alarm clock, or should it just be a plain card? Default: plain card.

Question 12, the session provenance line. When a work session files a capture through endsession, there is a line saying from which project, the outcome, and a link to Stats. It is the only place in the UI that shows where such a capture came from. Should it appear on the inbox card, the Stash card, or neither? Default: Stash card only, as a quiet line under the words.

Question 13, the token URL lane. Loading a page with a token in the URL plants the login cookie and redirects, and the service API still accepts that URL token for producers. Keep the owner URL lane and its hint on the sign-in wall? Or retire it for browsers, while producers keep theirs? Default: keep as is.

Question 14, one page versus the cap of 100. The ideas endpoint returns at most 100 items, and the Stash has 111 open. Raise the cap for the owner to 500, with the client still looping through pages, or do paging on the client only? Default: raise it.

Question 15, how many system cards show in the flow before the N-plus marker takes over. Default: 3, tuned in use.

Question 16, the voice waveform. Use a decorative bar pattern, seeded so it looks the same every time, plus the real length from the voice duration field. True amplitude decoding from the audio comes later as an add-on, because the list must never download audio just to draw bars. Default: yes.

Question 17, re-transcribe providers. Which chips appear: Groq and Inworld only, or Deepgram as well when its key is configured? The argument for Deepgram is that an explicit tap satisfies the rule that Deepgram is explicit only. Default: all three.

Question 18, re-transcribe's hidden overwrite. Today, re-transcribe also re-runs the categorizer and overwrites category, original category, tags and summary. That is the same overwrite you already killed in Re-run AI, and the log sends that endpoint's fate to Cohort D. Should that leg be dropped now, when the provider argument lands, so re-transcribe only updates the transcript, the duration and the provider? Default: drop it now.

Question 19, the system card after you send a reply with the pencil. The log says in one place that the card clears, and in another that routed items stay visible, a rule made for your own composer captures. The proposed reconciliation: the system card leaves the card flow, and shows in the on their way line until it is delivered. Default: yes.

Block C: System Cards and the Producer Contract

This block is about how machines and producers talk to your inbox, and it is the biggest one. Take it slowly.

Question 20, the carrier. Option A adds new optional fields to the existing ideas endpoints: sender, a severity of either needs-you or broken, a headline of at most 80 characters, a producer reference used as a self-close key, and a repo, meaning the courier route name. That keeps one single write door. Option B is a brand new system endpoint. Option C extends the service alert endpoint with an inbox lane. Default: A.

Question 21, lane and tokens. System items stay in the mine lane and are written by confined, owner-derived tokens, one per producer, with the pinkreminder SMS token as the model. The alternative is giving producers machines credentials and building a machines-to-inbox path. Default: mine lane, through confined tokens.

Question 22, the compatibility shim. Until producers migrate to the contract, Capture derives the fields itself. Sender comes from the bracket tag. Severity is needs-you. Headline is the first line, cut at 80 characters. Repo comes from a small seed map. This lets Leg A ship the new system cards right away. Default: yes.

Question 23, the bracket rule's fate. Once the contract exists, the old square-bracket text rule stays as a fallback until the producers endpoint shows zero bracketed writers from non-owner, non-session tokens for 30 days, measured. Then it is removed in one named diff. Default: yes, 30 days.

Question 24, the JSON door gap during the shim. Today the bracket rule only runs on the plain JSON door when auto-categorize is on or the category is off the list. So something like Chat-arkiv posted plainly lands as a normal card, and there are 316 such rows in history. During the shim window, should the bracket rule apply on the plain JSON path too, or should those rows stay normal cards? Default: apply it.

Question 25, sender to repo. The producer declares its own courier route name in the contract, one field, so Capture holds no mapping of its own. A small seed map covers the shim period. Popcorn2 selfcheck, the restore drill and Monitor go to floor. Gitsnap goes to parsnap. Chat-arkiv goes to chat-arkiv. WaspBee goes to utilities. TheAssistant and the paper scout go to theassistant. And PärPod goes to parpod. Default: yes.

Question 26, where your reply sentence is stored when you answer a system card. Option one, a comment row authored by you, with the delivery's reply field copied from it, so the courier note carries Pär says, followed by your sentence, under the original message. Option two, appended to the item text. Option three, the delivery field only. Default: the comment plus the delivery reply.

Question 27, all-good messages. When a producer sends an info or all-good message, should Capture reject it with a 422 error that explains the fix, or accept it and silently drop it? Default: reject with 422.

Question 28, the restore drill heartbeat. Today the drill's all-good message proves the inbox alert path is alive. Once all-good messages are pruned, where does that proof live? Theassistant watching the drill's stamp, a heartbeat page in Stats, or a Capture write-path probe on a reserved source reference. Default: theassistant.

Question 29, getting theassistant off the member path. Its ADHD paper scout digest currently lands in Requests through the member token. Option A, a confined owner-derived token in the mine lane, plus the contract fields. Option B, a machines lane path. And a related question: is a digest with no fault state a needs-you message, or is it the all-good class that should not be sent at all? Default: A, and the digest counts as needs-you, because it asks you to read something.

Question 30, sessions as producers. When a Claude Code session files something like floor, rule on X, through the owner token, is it a system card with the repo as sender and needs-you severity, or a normal card? Default: a system card under the shim, and after Leg A the capture skill gains an explicit system path where the session names sender, severity and headline.

Question 31, SMS. The bridge sends the sender as a field and drops the SMS-plus-phone-number prefix from the text. Carrier messages, like those from 71550, become a teal normal card rather than a system card. And while the shim runs, source SMS wins over category system for rendering. Default: field plus dropped prefix, carrier as a teal normal card, and yes to that precedence.

Question 32, the gruvkartor invoice ping. A request card in the people lane with its own tone, or a needs-you system card? Default: request card.

Question 33, the Reddit Shortcut. Drop its Reddit bracket, so your own saved links render as normal cards? Default: yes.

Question 34, the legacy Wall's this needs me button. Promoting a signal mints a mine-lane capture that has no severity and no headline. Should it set the contract fields, sender as the producer, needs-you, and the signal title as the headline, so it becomes a proper system card? Default: yes.

Question 35, the pinkserver watcher's one-shot messages. Each one either becomes needs-you or broken, or retires in favour of the keyed signals. Default: floor proposes a verdict per message in an inbox note, and you accept.

Question 36, the old todo row about routing bracketed items into signals, deferred back in July. Is it superseded by the ruling that the Wall is legacy? Default: yes, and the row moves to the log with its citation.

Block D: Repo Routing

Question 37, who owns the deliverable repo list, and what vocabulary it uses. This one blocks the Repo pill, the composer's Repo button, and the reply. Option A, theassistant publishes its resolved courier map to Capture on every pass, a small table using courier names. Option B, Capture reads the work repos table and derives basenames. Option C, a hand-kept list. In the interim, the last 3 come from capture routes and the list comes from work repos basenames. Default: A.

Question 38, decision D-02, the repo proposal, the one where the system asks which repo you are talking about and you confirm with one tap. Drop it along with enrichments, or keep it as a suggested chip inside the repo picker sheet with its own small store? Default: decide in the Cohort D track. It is not built in P4.

Question 39, courier version 1. After 30 days of logs showing zero hits on the tag query, from the courier and from generic by-tag reads, may the tag query endpoint and the repo-tag mirror write both go, in one commit? Typing a repo hashtag would keep granting authority. Default: yes, measured.

Block E: Stash, Search and Bulk

Question 40, bulk audience and bulk project. Neither is in the bulk action set, because both are on hold. Accept that gap, or add them? Default: accept the gap. The endpoints stay.

Question 41, shift-click to exclude a tag on the Stash tag row. Keep it? Default: keep. It is one line of code.

Question 42, the committed pin state on the Stash card. Commit stays a work button, and the card has no chip for it. Should the button show as pressed when the item is committed? Default: yes.

Question 43, setting audience on a me item. The card only shows audience when it is not me, so how do you set it in the first place? Default: a dashed plus-for option inside the chip picker, not in the resting chip row.

Question 44, project badges on the Stash card. 17 items are linked to projects. Show a read-only badge, or leave projects to the legacy views? Default: read-only badge.

Question 45, freshness or age on the Stash card. You already ruled no aging edge on the inbox card. Same for Stash? Default: no age signal.

Question 46, the Requests door when nothing is waiting. With zero requests there is no deck, and the log says the footer links return if the top slot goes. Default: the footer word Requests shows only while nothing waits, and hides when the deck is on screen. The requests route itself keeps working.

Question 47, extras on the contact page. An end mark, yes. No pager. A button to move to Stash, which does not exist today. And reply-to-sender goes on the after-rebuild list. Default: as written.

Question 48, the old all bookmark. Should it open the legacy Library, the command-K palette, or the Stash? Default: the legacy Library.

Block F: Leftovers From the Old Plan

Question 49, how much of enrichments to kill. Option a, stop the gist write only and keep the table. Option b, also drop the iPhone app's client category and Swedish client transcript hints. Option c, drop the whole table, including the Cohort D route proposal and the Cohort E PärMCP hints. Default: a, now in Leg A, and decide b or c at Cohort D.

Question 50, voice intents after the gist dies. Cohort D as written stops intents, but your September 6 ruling keeps the call. Confirm that all four intents stay: schedule, which goes to Time and the legacy Today; promote, which goes to Stash; cancel; and research. And confirm that Cohort D means shrinking the categorizer down to the intent detector plus a one-provider canary. Default: yes.

Question 51, the chute. That is the one-item-at-a-time view from your July 26 capture, and it was the headline of the old P4 plan. It never appeared in the card rounds. Dropped, parked, or do the j and k keys stand in for it? Default: parked, and j and k stand in.

Question 52, the voice page. It was ticked for removal, and it writes a 365-day cookie that JavaScript can read, which is exactly what the auth policy forbids. Remove it with Leg A after a 30-day log check, in one revertable commit. Or move it to the legacy section. Or keep it with the cookie fixed. Default: remove.

Question 53, the quick-note endpoint. It was ticked for removal before the Mac's Capture Selected Text quick action started using it. Keep it as is, including its legacy project fast lane, or repoint the quick action to the ideas endpoint and retire it? Default: keep.

Question 54, the Cohort E journal. Yes or no on the PärMCP delivery journal, or park it until after the UI build? Default: park.

Question 55, PärMCP category and tags at Cohort E. Should PärMCP write what the Stash card shows, keep them as invisible hints, or drop them? Default: decide at Cohort E.

Question 56, a note to Time. Time's due-items panel reads horizon from the items view, and question 2 decides whether that data survives. File the note to Time's inbox now? Default: yes.

Question 57, the capture skill's accept verb. It calls the accept-suggestions endpoint, which nothing has fed since Cohort A. Retire the verb together with the route in Cohort D, and not before? Default: yes.

Block G: The iPhone App

Question 58, the Capture hold on the iOS repo, set October 8. Lift it now for spec-only work, meaning the contract note in the iOS inbox, and for code after Leg A ships? Default: spec-only now, building after Leg A.

Question 59, how the app stamps its build. D-09 already says it should. The mechanism: a ParKit build header on every request, recorded as a span attribute and as a nullable client build column on the create door. Default: yes to both.

Question 60, the phone inbox look. Adopt the locked card, with the place, text only, the Stash, Repo and done buttons, the sparkle menu and the waveform? Or keep the compact list row with renamed verbs? Default: list row first in phase P-two, locked card later in phase P-three.

Question 61, the summary on the phone. The detail sheet shows the 100-character deterministic summary as a title above the transcript. Drop it? Default: drop it in phase P-two.

Question 62, trash swipe. The phone inbox has a swipe to trash, while the web rule is that delete lives in Stash. Default: keep the swipe.

Question 63, system cards and Requests on the phone. System items show up as plain rows today. Requests never reach the phone, though SMS replies already arrive as normal mine-lane rows. Default: system rows stay visible, get the system card look in phase P-three, and get the reply pencil once the repo field exists. Requests stay off the phone until request buttons are designed on the web.

Question 64, the phone's structure. Keep the 5-tab bar with Today where it is, which is safe under D-09, and rename the Browse scopes to Stash, Pärl, OneDay and Done? Or restructure around Inbox, Stash, Pärl and OneDay? Default: keep the 5 tabs and rename the scopes.

Question 65, a web-tab bridge. Add the rebuilt Capture website as a surface in the app's Web tab before the native catch-up, and remove it when the native card ships? Default: yes.

Question 66, how much Stash on the phone. Minimal means renamed scopes, every move and work verb that exists today as sheet buttons, and notes through comments. The alternative is the full Stash card with chips, filters, bulk and merge. Default: minimal.

Question 67, close the iOS forpar items for Projects and Deadlines, marked as legacy and on hold, with citations? Default: yes.

Question 68, the Today tab on the phone while Today is on hold. Leave it in place, or move it behind a Legacy entry? Default: leave it.

Question 69, the place phrase on the phone. Show it in phase P-three, using the place field Leg A adds? Default: yes.

Question 70, iOS hints after question 49. If the enrichments table goes, the app stops sending its category and transcript hints, and the on-device categorizer stays on the device, used only for the post-capture chip. Default: yes.

Block H: Housekeeping

Question 71, the card lab after the build. Move it under the card rounds plan folder, committed, as the log's cited reference? Or leave it gitignored inside static? Default: move it and commit.

Question 72, the 316 bracketed rows that were never classified as system. Leave them as they are, or backfill them once the shim exists? Default: leave them.

Question 73, the visual rounds still owed. Each one gets 2 to 4 options, shown inside the leg that needs it. They are: the reply field, the system all-page, the Pärl and OneDay colour schemes, the Legacy page, the Archive look, the four spark hues and their hour bands, the deck at phone width, and the composer after a repo pick. Run them? Default: yes.

Already Ruled, No Answer Needed

A few things sound like questions but are already settled by the log, so they are here for information only. The place phrase ships with geocoder names now, and the location descriptors stay empty until Where ports its updater. The Usage view stays in the footer, bigger and clearer. The s key means Stash, and the one-key horizon now shortcut goes, though horizon stays editable through the Stash when chip.

The wall line stays as it is until the Wall review. The filter toolbar leaves the inbox, and every control gets a named home on the Stash or the Done view. The old handoff's removal list gets annotated row by row as carried, legacy or killed. Stash is just a patch that sets nature to task, with no new endpoint, and promote keeps answering until the capture skill is repointed. Note search starts as a join on comments, and only gets a full text column if it proves slow.

[calm] That is all 73. If you agree with everything, the answer is one word, and the build can start. If one of them made you frown somewhere around the middle, that frown is the whole reason this list exists. Say the number, say what you want instead, and the rest stays default.