Meet Notes app

Joe read out the site work list for Claude at the end of the Oct 19 call, in this order: latest answer on top; faster answers; confirm with a button after sign-in; after-call to-do email, or each person's to-dos in the app; a link with every doc; simple for anyone; works on a phone; small review fixes; Claude runs the call more actively. That order is recorded as agreed by Joe and Reid but still carries an unsure mark, since it was never read back. Oct 20 added four asks: the opening agenda, a blocking to-do at the top of the page, typing answers to the start questions, and staying on the same page when the call drops; three of those were working on the Oct 22 practice calls. The Oct 22 name box and drop fixes are done as far as the practice calls can show. Oct 26 changed the picture in two ways. First, there is now work that comes before any page item: running the meeting app on Reid's cloud server so anyone can use it, then moving it into its own code home, then joining it with Reid's intake app and the inventory view behind one front door. Second, Reid's walk-through turned up six page problems. Suggested order, for the group to confirm or change: (1) run the app on Reid's server; (2) the walk-through problems that make it look like nothing happened (the vanishing question, not showing as signed in, the hard-to-find read-back), which are really the Oct 19 latest-answer-on-top item; (3) how a yes gets counted, because a wrong yes puts a false decision on the record; (4) a shorter agenda that shows only what matters this call; (5) the rest of the Oct 19 list in its order, with the Ask box label and link sharing folded into the simple-for-anyone and link-with-every-doc items; (6) moving the meeting app into its own code home and joining the parts, once Reid's write-up on the plan is in. Still needing a slot: keeping practice-call content out of the real record, which Claude suggests putting with the shorter-agenda work since both are about clutter.

Joe asked on Oct 19 that after each call, each person gets an email with their own to-do list in plain text, one item per line, so they can copy each item straight into a work session. If email is not set up yet, the fallback is that each person opens the app and sees their own to-dos and what they contributed. Options side by side: (1) email only; (2) in the app only, under each person's name; (3) both, with the app as the record and the email as the nudge. The Oct 26 call showed why this matters beyond to-dos: Joe had given Claude answers to Reid's questions, and they never reached Reid. Nothing in the app today makes sure a message meant for one person gets to that person. So whichever option is picked, it should carry more than to-dos: anything addressed to a person, such as answers to their questions or a write-up they are waiting on, should land in the same place as their to-dos, and the sender should be able to see that it arrived. Also carried from Oct 16: to-dos were not read back before the call ended, so their owners stayed unconfirmed. On Oct 26 most of the new to-dos did get an owner's yes during the call, which suggests the read-back is working when the call has time for it; the two overtime chimes on Oct 26 are a sign that time is the limit.

New on Oct 26. The call's agenda had six real items and then about forty more, one for every open to-do in the shared list, each marked as needing an update. Many of those are old: some go back to Oct 9, most have no owner who said yes and no day, a few are already done in practice but still open (the name box fix and the listener drop fix both held on the Oct 22 practice calls), and two are the same practice-call line about the scanner, filed twice. A list that long cannot be read before a call, which breaks the rule that reports are short enough to read ahead, and it hides the few to-dos that matter this week. Options side by side: (1) the agenda only shows to-dos that are due, blocking, or tied to a goal of this call, and the rest stay in the to-do list where they can be looked up; (2) once a week, at the start of a call, Claude reads out the old to-dos in one batch and the group says keep, done or drop for each, so the list gets pruned on a schedule; (3) to-dos with no confirmed owner and no day fade into a parked list after a set number of calls, and come back only when someone asks; (4) Claude marks to-dos that look done, such as fixes that passed a practice call, as probably done and asks the owner to tap yes. These can go together: option 1 keeps the agenda short now, and option 2 or 4 keeps the list itself honest. Claude does not close or delete to-dos on its own, so whichever is picked, the actual clearing waits on a person's yes.

The team went with the shared-machine shape on Oct 19: one app on a cloud server, sign in with a Claude account, one copy of the records, no install on anyone's laptop. The Oct 22 practice calls ran on the new page, but the Oct 26 call set a to-do for Claude to move the meeting app onto the cloud server Reid set up last week, so anyone can use it. That reads as: the app is not yet running there for everyone, and until it is, calls still depend on Joe's setup. The old to-do to make the tool work on any teammate's computer, including Windows, is covered by that move and could be closed once it is done; the group can say so. Still open: whether the listening part (joining the Google Meet and hearing the call) runs on the server too, or still on one person's machine. Today it still runs on Joe's Mac. Three things from Oct 22 come back to that: the Chrome Allow prompt only exists because the listener runs in someone's browser; the Oct 20 drops happened on the listener; and on the third evening practice call Joe's Mac went to sleep before the closeout ran. Two more limits a teammate would hit on a first solo call: a second person on a different Google account could not be let into the Meet automatically, and actions sent to the page over the public link were refused because the public address had not been set on the server. Options side by side, unchanged: (1) listener on the cloud server, which removes the Chrome prompt, the sleep problem and the dependence on one person, but means the server needs its own way to join a Meet; (2) listener stays on one person's machine, with a rule that the machine stays awake and plugged in during calls; (3) listener on the server, with a person's machine as a fallback when the server cannot join. Moving the app onto Reid's server this week is a natural moment to try option 1 or 3, since the server is being set up anyway.

On Oct 19 Joe said the meeting app and the deal intake web app shown to Keegan can be one application running in the cloud. Anyone with a Claude account signs in to join and run calls. Keegan said the other weekly meetings come off the calendar; this AI meeting replaces them. On Oct 26 Joe and Reid took this further, marked as agreed but still carrying an unsure mark: one app does everything. Reid's intake app, the inventory's explore view, Reid's test rig and ruling tools, and this meeting app all sit in one place for the team, but each part keeps its own code home behind one front door, so each part stays small enough for Claude to work on without tripping over the others. Two to-dos follow from it for Claude: move the meeting app into its own code home, and then bring the parts together behind the one front door. Reid is sending Joe a write-up of the plan for the code homes after the call, and that write-up is the thing to read before the joining work starts. Also from Oct 26: right after the call, Claude is to work with Reid to run the meeting app from the cloud server Reid set up last week, so anyone can use it; the first step is getting the server's address and access from Reid. Still not said yes to: whether each person gets their own Claude seat, which came up on Oct 19 when the shared allowance ran out mid-call. Suggested order, for the group: get the meeting app running on Reid's server first, since that is what lets Reid and Keegan use it without Joe; then split it into its own code home; then join the parts. Doing the split first would mean moving the app twice.

New on Oct 26. When Claude asks a yes-or-no question in the call, such as reading back a decision, anything said next was taken as the answer, even when people were talking about something else. That matters because a decision marked as confirmed is supposed to mean the people in the call actually agreed to it. Options side by side: (1) Claude only counts a clear yes or no, and anything else leaves the item waiting; (2) Claude counts nothing by voice until someone presses the yes button on the page, and voice only reminds people the item is waiting; (3) voice counts, but Claude says back what it heard, such as 'Joe said yes to this one', and gives a few seconds for anyone to say no before it is filed; (4) yes by voice or button, with the button as the only way to say no or change it. Option 1 is the smallest change. Option 3 keeps voice fast and still lets people catch a wrong yes. Whichever is picked, a yes should show who gave it, so the record says who agreed and not just that someone did.

The Oct 26 call was the first real call Reid ran on the new page, with Joe, and it opened with a ten minute walk-through for Reid. That walk-through is the check the practice calls were leading up to: can a teammate who did not build the page get through it without help. The answer was not yet. Six problems came out of it, all now on one to-do for Claude, not yet confirmed: (1) a typed question vanished after Reid pressed send, so he could not tell it had gone through; (2) the Ask box looks like a name box, so it is not clear what to type where; (3) the page did not show Reid as signed in; (4) the read-back post, where Claude reads decisions back for a yes, was hard to find; (5) any talk during a yes-or-no question was counted as the answer, even talk about something else; (6) there is no way to share a link to something on the page. Problems 1, 3 and 4 are the same complaint Reid made on Oct 19, that he could not tell anything had happened, so they belong with the latest-answer-on-top item at the front of the work list. Problem 5 has its own part of this design, on how a yes gets counted. Problem 6 goes with the link-with-every-doc item. Suggested, for the group: after these are fixed, run the practice checklist once with Reid driving instead of Joe or Claude, and only count the page as ready for teammates when Reid gets through it alone. The Oct 20 idea of Joe and Reid sitting down for an hour to walk through the app together is still open, and this walk-through may count as most of it; the group can say whether it does.

Asked for by Joe on Oct 20, not yet confirmed by the group. Every call opens with an agenda that Claude manages. Claude proposes the agenda from past calls and from what the group says it wants, and nothing else starts until the agenda is set. Item one is always the three start questions (one idea, one decision, one question), and people can type their answers on the page instead of saying them. If a to-do from last time blocks the call, it shows at the top of the page right away and can hold the call until it is dealt with, but the group can choose to skip past it. All four Oct 22 practice calls ran on an agenda card of this shape, with items marked done, now, next and later. One small thing the third evening call showed: when the agenda got set before anyone typed, the start answers were skipped, and on the fourth call they were typed first and saved. So the order of the first two steps matters and the page should make it plain which comes first, or let the start answers be typed either before or after the agenda is set. Still open, from Joe's Oct 20 question: how the work done between calls (overnight drafts and the written updates) shows up inside the call so the loop closes at the start. Options side by side: (1) the agenda's first item lists what Claude did since last time and waits for a yes or a no on each piece; (2) between-call work shows as a short note at the top of the page but is not an agenda item, so it does not take air time unless someone asks; (3) Claude reads it back out loud at the start, the same way the closeout is read at the end. Option 1 fits the rule that nothing is final until a meeting confirms it.

New on Oct 22, proposed by Claude for the group. The practice calls use a fixed script so the page has something to show: one idea about moving the scanner work, one decision about using the Excel inventory for the title index, and one question about the checker. Those lines were never meant as real. But the app filed them the same way it files a real call. After the two evening calls the shared to-do list has the scanner idea twice, as two separate to-dos with no owner, and the closeout of the fourth call lists the Excel inventory decision as undecided and waiting on Joe. If this keeps up, every practice call adds a few made-up items to the record that Joe or Reid then have to notice and clear, and the home page can end up pointing at a decision nobody actually raised. Options side by side: (1) a practice switch on the call, so everything said is filed into a throwaway copy and dropped at the end, with only the pass or fail of the checklist kept; (2) practice content is filed as usual but tagged as practice, and anything tagged that way stays off the home page, the to-do lists and the undecided list; (3) practice calls run against a separate copy of the records, so the real one is never touched; (4) leave it as it is and clean up by hand after each practice call. Option 1 is the simplest for people, since nobody has to remember to clean up. Option 4 is what happens today. Whichever is picked, the two scanner to-dos and the Excel inventory item from Oct 22 need a human to say they are practice leftovers before they are removed, because Claude does not delete records on its own.

The Oct 20 call dropped twice and the listener fell out with it, so Joe asked that a call which drops and rejoins keeps the same notes page and record, with no second Allow prompt in Chrome. This was tested on purpose on Oct 22 across three practice calls with two faults. Denying the Chrome prompt once and then allowing it passed every time: the listener came back by itself. Reloading the Meet tab, waiting and rejoining failed on the afternoon call, when the page said the call had ended while Joe was still in it, and then passed on both evening calls after a fix: the page sat on the rejoin screen for about twelve seconds and did not say the call had ended. So as of Oct 22 the listener recovers and the page's idea of whether the call is still on holds through a short reload. What is not yet settled is the rule behind it, because it only got a pass on a short, planned reload. Options side by side, so the group can say which rule they want: (1) the page waits a set grace period after losing the call before it says the call ended, which is what the Oct 22 pass looks like, and the question is how long that period should be and what happens on a longer drop; (2) the call only ends when someone says so or presses an end button, and a dropped listener shows as a warning instead of an ending; (3) both, with the grace period for short blips and the explicit end for everything else. Option 2 matches how the closeout already works, since the last agenda item is to leave and say we are done. One related thing from the third evening call: the listener still runs on Joe's Mac, and when the Mac went to sleep the closeout did not run. A drop caused by the machine itself is not covered by any of the three options above and points at the question of where the listener runs.