Decisions still open

These are reading copies of the existing questions from Workstream A. The stylebook question was approved and is already installed. You can answer the remaining questions in chat; these pages do not submit approvals.

Should Wob ever move an event that has other people on it?

WOB-127 (PR 304, from the cloud session) teaches Wob to move the time of an event you made yourself, such as your dentist appointment. It only does that after you 👍 the exact line, for example "Move Dentist from Tue 3:00 PM to Thu 3:00–4:00 PM". It changes the time and nothing else, then reads the calendar back. Tonight it gets its language-server pass and one real move of a labelled test event that the work creates and deletes. Nothing reaches Wob's phone side until its runtime lines get your Approve later.

Should Wob ever move an event that has other people on it?

The build refuses those today. Moving one changes the invitation for everyone on it, and depending on the calendar it may send them an update or a cancellation-and-reinvite. That would be Wob effectively messaging people for you.

• Keep refusing — Wob says it can't move shared events and you move them yourself
• Allow with a warning — the line you 👍 says "this sends an update to N people"
• Decide later

Recommended: Keep refusing Holds up: nothing tonight; the PR ships refusing them

This question was skipped at 08:45 EDT. No answer has been assumed.

How should helpers be kept from claiming another job's identity before domain memory is turned on?

WOB-138 turned out bigger than a code fix. Astra's reproductions (her note) show a helper can claim another job's identity in all six domains. Domain memory picks whose lessons a helper sees by that identity. Nothing leaks today, because memory is off.

A helper runs a full shell as your own macOS user, so it can read any token or record WobOS could use to check who it is. No change inside WobOS's own files can stop that. A real fix needs helpers to run somewhere that can't read Wob's state.

How should helpers be kept from claiming another job's identity before domain memory is turned on?

Holds up: turning on domain memory (WOB-116)

• Design a real boundary as its own slice — helpers run as a separate Mac user or in a sandbox that can't read Wob's records, with one trusted way to start them
• Add a light label check now that catches honest mistakes only, and keep memory off until the real boundary exists
• Accept the light label check as enough and allow domain memory with that known gap

Recommended: Design a real boundary as its own slice — helpers run as a separate Mac user or in a sandbox that can't read Wob's records, with one trusted way to start them

This question was skipped at 08:45 EDT. No answer has been assumed.

How should the two catch jobs come back on?

A correction to the question above: I described the first run too loosely, and the cost figure covers only iMessage. Same choice, no default, and both jobs are still off.

• iMessage, on the new runner. The first run collects the past month of conversations, read and unread, in both directions. It then works through them in batches over about 10 runs, which is roughly one day of the job's 14 hourly slots. That first sweep is projected at $70–95 from item counts, not measured. If the month is large, the final summary leaves some conversations' notes out and says so (in a synthetic 213-conversation month, 53 were left out).
• Instagram. There's no projection. Its old collector is the $2–6-an-hour run you turned off on 17 September. Astra promotes the cheaper new collector after this morning's install.

How should the two catch jobs come back on?

PR 321 limits the model to the commands the two prompts name. Turning a job on is one command each, and one command turns it back off.

• After you look at PR 321 — merge the profile, then turn both on and accept the projected iMessage first-sweep cost
• Turn both on now with the current profile, accepting the projected $70–95 iMessage first sweep
• Keep both off for now

Recommended: After you look at PR 321 — merge the profile, then turn both on and accept the projected iMessage first-sweep cost Holds up: catch-job activation

This question was skipped at 08:45 EDT. No answer has been assumed.