CC-03 The top navigation bar breaks at different screen sizes

Status: 🔴 Not started.

What. The header at the top of the console sizes wrong, jumps, and glitches as the window or device changes. This needs a real look, not a patch: measure it at phone, tablet, laptop and wide desktop, in light and dark, with long and short organization names, with many tabs and few, and fix every case.

Done looks like. A short written breakdown of what was wrong at each size (in the pull request), the fixes, and screenshots at each size proving it holds. Verified live on care-co.loveisahabit.org, not only in a local preview.

Drew, 2026-09-17: "Also we need to correct the nav bar in all screensizes and view ports at the top of the care console... it sizes incorrectly, glitches, changes and has a ton of errors... do a ui/ux breakdown to finetune it, fix it and verify it's completion"

CC-04 One home for clinicians: availability and profile together

Status: 🔴 Not started.

What. When a clinician signs in, the console opens straight to their availability. That is good. But their profile lives on a separate tab, and that tab shows no availability — which feels odd, because the two are the same person's information. Give clinicians one landing tab: availability front and centre, with an Update my info button that opens their profile in a popup (see CC-15 for the popup itself).

Done looks like. A clinician has one home tab. It shows availability and opens the profile editor as a popup. The separate profile tab is gone for clinicians (admins keep what they have).

Drew, 2026-09-17: "Also the fact that the clinician comes to the home pages and it auto opens to availablitiy is great... but also they already have access to their profile thorugh that it seems odd to me that availability content is NOT available in the profile tab... (to me maybe there should just be one availability, landing page tab for clinicians which gives access to updating ones profile in the popup"

CC-06 The Directory tab should become "Send a referral"

Status: 🔴 Not started. Pairs with CC-19 and CC-22.

What. For a clinician, a "Directory" is a thing to browse. What they actually want to do is send someone to the right place. Rename and reshape the tab around that job: search, find the right organization or person, and send the referral — with the partner-organization search from CC-19 behind it.

Done looks like. The tab reads "Send a referral" for clinicians, opens on a search, and ends in a sent referral that is tracked (see CC-22 for tracking).

Drew, 2026-09-17: "The directory tab also doesn't make much sense for clinicians (it might be better as a "Send a refferal tab"..."

CC-09 A "Match now" button inside the call script

Status: 🔴 Not started.

What. Next to the note button on the script, add a Match now button. It opens the matching tool as a popup with everything already gathered on the call filled in (age, concerns, insurance, preferences — whatever the script has captured so far). From any point in the call, one tap to matches. Results come in this order: our own organization first, then partner organizations, then other relevant organizations.

Done looks like. Start a call, answer a few script questions, tap Match now — the popup opens with those answers pre-filled and shows own-org results first. Works from any step of the script.

Drew, 2026-09-17: "same with the old popup coordinator console matching system... so smooth from any point in the call it was easy to match (maybe another little button next to the note button on the script that says "match now" and invites the popup than with all the relevant info added... remember the goal is for this all to allow high qaulity matching for coordinators to first see their org, than other partner org, than other relevant orgs... i feel sad bc i've tried to update this with you before but you never were able to make it fully work so i really need your help to make it work this time..."

CC-10 A form inside the call script that sends the note for you

Status: 🔴 Not started.

What. The original clinician console could send the script's note, already filled in, through a form. Give every organization a place in Organization → Call scripting to paste a GoHighLevel form embed code, and have the call script show that form with the note pre-filled. Bring the form over from the Kentlands coordinator console as the first, working example.

Done looks like. An admin pastes an embed code once. A coordinator finishes a call, opens the form from the script, and the note is already in it. Submitting sends it through the organization's own form.

Drew, 2026-09-17: "(our original clinician console also had teh ability to send the script note autofilled via the form (you can leave a place for a ghl form embed code and auto place the form from the kentpsych coordinator console over to the care console )"

CC-11 Every organization can build and edit its own call script

Status: 🔴 Not started. Depends on CC-07.

What. Creating a call script inside the console should be possible and easy for every organization — not a thing only we set up. Admins and owners should be able to create, edit, manage and test their script without help. After CC-07 combines the tabs, add an Edit / customize your call script banner at the top of the admin's screen that opens the editor.

Done looks like. An admin at any organization can open the editor from the banner, change a step, test it as a coordinator would see it, and save — with no one from our team involved.

Drew, 2026-09-17: "I actually do want creating a call script inside the care console to accessible and possible for everyone... admins /owners should have the easy ability to create and manage the call script and edit it and test it easily (maybe after we update and consolidate those mulitple tabs into one call script tab we can allow admins /owners to have a edit /customize the call script banner at the top of their screens)"

CC-12 Port the Kentlands matching "charm" into the shared matcher

Status: 🔴 Not started. Long-standing; the standing rule is that Kentlands' matching improvements port in, their look does not.

What. Over months, the Kentlands matching tool picked up dozens of small tunings — the little things that make it match well: keyword syncing, how concerns map to specialties, how ties break, what gets shown and hidden. Go through the Kentlands repository, list every one of those tunings, and bring each into the shared matcher (packages/matcher-core) so every organization benefits.

Done looks like. A written list of each tuning found, and for each: ported, or deliberately left out with a reason. The shared matcher's tests cover the ported ones. Kentlands' own copy is not modified.

Drew, 2026-09-17: "We need to go through the kp matching tool "charm" (all the little things we updated on kentpsych repo to make the matching tool match well … even all of the key word syncing we used..."

CC-13 Simplify the matching sliders and the result limit

Status: 🟡 Started. A "How many people a search shows" setting (1–12) shipped 2026-09-17 in Organization → Matching. The rest is open.

What. Redo and simplify the matching sliders so an organization can do a lot of high-quality things without a manual. The result limit should go from best 1 to unlimited, not stop at 12. The sliders should be fewer, clearer, and worded for a practice owner, not an engineer.

Done looks like. The Matching tab reads simply. The limit control offers 1 → unlimited. Every control has one plain sentence saying what it changes. A search on a live website respects the saved settings within a minute.

Drew, 2026-09-17: "(and redo and simplify the matching sliders so that it can do lots of user firendsly high quality things like set the limit of clinicians that could pop up (aka best 1 to unlimited)..."

Drew, earlier in September 2026: "some searches only pop up 3 clincians... we need to create the ability to decide how many clinicians we want to show up as a max in searches..."

CC-14 Let a match end in an action: form, text, or templated email

Status: 🔴 Not started.

What. When a search finds the right person, the next step should be one tap. Give each organization the choice of what that tap does: open a GoHighLevel form, send a text message, or send a templated email — and let them edit that template themselves.

Done looks like. In Matching, an admin picks the action and (for email) edits the template. On the public widget and in the console, a match result shows that action. Texting depends on CC-31.

Drew, 2026-09-17: "we should alsoo give poeple the choice to add a ghl form in their or send a text message or something else like send a templated email (and edit that templated email)"

CC-15 Clinicians update their own information

Status: 🔴 Not started. Pairs with CC-04.

What. Today an admin can edit a team member's specialties and every other field through the Edit team member popup on the Team tab — and that popup is good. Clinicians should be able to do the same for themselves: an Update my info button on their availability home opens the same kind of popup, showing only their own record. Reuse the existing popup rather than building a second one; popups are the preferred shape here.

Done looks like. A clinician signs in, taps Update my info, changes a specialty, saves, and the change shows up everywhere that record is read — the directory, the matcher, the public widget. An admin's view of that person shows the same change.

Drew, 2026-09-17: "The clincians info --> specialities and all variables need to be updatable in the console by the own clinician(not just the admin --> the edit teamm ember for admins pop up is awesome and it could be like that for clinicians updating (great ui /ux already there to duplicate or use in some other way when someone clicks update my info on the clinician home page availabiltiy view (i like popups for this better)"

CC-16 Our own secure database, with two-way sync to GoHighLevel

Status: 🔴 Not started. A foundation item — the biggest on this list. Also the fix for "a practice's own GoHighLevel and the hub copy disagree" (see the org-sync notes in this repo's history).

What. Right now GoHighLevel is where clinician data truly lives and the console reads it. Flip that: the care console keeps its own secure database as the source of truth for every clinician at every organization. GoHighLevel becomes something we sync with, both directions and automatically — when a practice with its own GoHighLevel (Kentlands, Kid Matters, and every practice after) updates a custom object, the console gets it; when someone updates their record in the console, their GoHighLevel custom object gets it. A practice's token is what carries the update, so each organization only ever touches its own data.

Done looks like. A written design first (one page, plain English on top): what lives in the database, what syncs, what wins on a conflict, and how a practice connects its token. Then: the database, the sync in both directions, and one practice (Kid Matters) running on it live with a hand diff proving nothing was lost.

Drew, 2026-09-17: "We need to create a secure database for all of the data to live for all of the clincians in the care console (rather than ghl being the source of truth, on the to do list we need to add the ability to update ghl custom objects for KP and all practices so that the token can send updates directly to the care console and back and forth automatically)"

CC-17 Make Kentlands and Kid Matters verified partner organizations by hand

Status: 🔴 Not started. Small, and a prerequisite for CC-18's checkmark.

What. Only two organizations are verified today: Kentlands and Kid Matters. Mark both as verified partner organizations by hand, so the checkmark in CC-18 has someone to show it on from day one.

Done looks like. Both tenants carry the verified flag in the registry; the directory shows the mark on both.

Drew, 2026-09-17: "(varified practices only inlcude kp and kid matters which need to be made partner orgs manuelly--> add to the to do list)"

CC-18 Gather organizations we haven't onboarded yet, and mark who is verified

Status: 🔴 Not started.

What. A search that only knows the organizations who have signed up is a small search. Start building up a wider set: gather public information about practices and programs in the areas we serve, bring them into the database (CC-16) as unverified, and let searches include them. Show a green checkmark on the profile avatar for verified organizations and verified clinicians, so the difference is obvious at a glance.

Done looks like. A documented, repeatable way to gather and refresh unverified listings (what we collect, from where, how often, and how a practice asks to be removed). Searches return verified and unverified results, visibly different. The checkmark shows on avatars.

Drew, 2026-09-17: "and speaking of the data base for all orgs on our care console... we need to start beafing up and scraping data and encorporating unverified practices into our searches … (we need like a green checkmark for varied orgs and clinicians on the profile avatar)"

CC-19 Search across partner organizations

Status: 🔴 Not started. Feeds CC-06 and CC-22.

What. Clinicians — and anyone else with a login — should be able to search partner organizations quickly: to refer someone, or just to research who does what nearby. Today the search inside the console reaches one matcher; it needs to reach the whole network.

Done looks like. From the Send a referral tab (CC-06), a search by need, insurance, age or area returns people and programs across every partner organization, with verified ones marked (CC-18).

Drew, 2026-09-17: "we need to start building the search functionality for partner orgs as well so clincians can do easy searches to reffer or research and other individual too"

CC-20 A search bar at the top of Messages

Status: 🔴 Not started.

What. Put a search bar at the top of the Messages tab. Type a name and find the conversation, or start a new one if it does not exist yet. Think it through as a user would: what happens with no results, with two people of the same name, on a phone, in dark mode.

Done looks like. Built, verified live, and double-checked for friendliness on phone and desktop. A short QA note in the pull request listing the cases tried.

Drew, 2026-09-17: "Also at the top of the messages tab I think should be a search bar to easily search and find or create a new chat. build and verify, double check and think through for quality assurance and userfirendliness... these are all crucial decisions..."

CC-22 Start a conversation from the directory, and suggest partnerships

Status: 🔴 Not started. After CC-06 and CC-19.

What. Once the directory has become Send a referral, connect it to Messages:

• In the partner section of chats, a button opens a popup to search for new clinicians or programs and start a conversation with them.
• A "Make a partnership connection" button — for reaching out to a whole practice (routed to one representative). A directory algorithm suggests complementary partners: practices nearby whose strengths fill the gaps in ours, so the suggestion has a reason attached.
• A "Make a referral" button — about a specific client. The wording and the flow are built around that idea, and a referral is where the covered chat is sometimes the right channel.
• Both kinds of contact are tracked: partner contacts and referral contacts, separately, so an organization can see who it has reached out to and why.

Done looks like. Both buttons live in the console; a partnership suggestion shows its reason; both contact types appear in a simple tracked list per organization.

Drew, 2026-09-17: "on the note of the messaging tab, after we make the updates to the directory / make a refferal page, individuals could be encouraged with a button that turns to a popup to search for new clinicins or programs in the parnter secotion of chats and begin a conversation (potential complementary refferal suggestions is a directory algorithm that matches refferal gaps to allow for potential parnterships in nearby areas that support each other in key gaps... a make a potential partnership connection button should be available and it could be either with the entire practice(going to one representantive) or with an entire practice... if a org staff member goes the "make a refferaL" that is about a specific client and the button they click should be based around that idea and both partner and refferal contacts should be tracked accordingly... refferalls also are where reaching out via a hippa compliant widget is sometimes ideal..."

CC-23 Schedule a call from inside a conversation

Status: 🔴 Not started.

What. Two clinicians at different practices caring for the same person need to talk. That is the plain case for a Schedule a call action inside a conversation: pick a time, both get it on their calendar, and the conversation keeps the record. This also gives the console a natural way to notice who is active (see CC-34) without watching anyone.

Done looks like. In any conversation, Schedule a call proposes a time, the other side accepts, and both get a calendar entry. Verified between two real logins at two organizations.

Drew, 2026-09-17: "another way that clinicians might organize their contacts are partner therapists who they're managing a client with, this a coordination of care situtation is a prime example of why we have talked about a "schedule a call" feature that can be accessed in messaging converssations"

CC-25 We never send the invitation — the person does

Status: 🔵 Needs one confirmation from Drew, then small.

What. An invitation should come from a person the partner already knows, not from our platform. The Invite an organization tool already offers Copy link, Copy email and an open in your mail app button. It also has a path where the backend sends the email itself (the invite route accepts a send option). Turn that path off so the platform never emails a partner directly, and make the copy-and-send-it-yourself path the only one. Add a text message option next to email (CC-26).

Confirm first. The same backend route is used when an admin adds a staff member to their own team. Drew's instruction is about partners; the question is whether staff invitations should also stop going out from the platform. Default if no answer: partners never, staff unchanged.

Done looks like. No code path sends a partner invitation from our servers. The tool hands the person a ready message and gets out of the way.

Drew, 2026-09-17: "Also as for the invite an org tab ---> I think we should give them a message to send (and not send emails on behalf of them--> we need them to send the email)..."

Drew, 2026-09-17: "(Again we don't want emails sending from our platform directly to partners) we need to encourage each org to reach out directly)"

CC-26 Two ready-made invitation messages

Status: 🔴 Not started.

What. Offer two messages, each as an email and as a short text:

1. Join us — "Hi, to help us coordinate care together, join here…" — for a practice we want in the network.
2. Keep my information current — "So I can send referrals to you more easily, could you fill out this short form so what I have about you is up to date…" — for a practice we already refer to.

Keep the current message's warmth; it is liked. Get creative with the wording, keep it short, and let the sender edit before copying. The current default, kept here so it is not lost:

Hi there,

We use a shared referral network to coordinate care and send and receive referrals between organizations. I'd love to have you in it.

You can join and set up your own free portal here (takes about a minute):

Where. The emailBody function in apps/liah-console/tools/network/invite/invite.js.

Done looks like. Two message choices, each with an email and a text version, editable, copyable, and openable in the person's own mail or messages app.

Drew, 2026-09-17: "secondly we want the email to essentialy have two email or text options ---> 1) being Hi to help coordinate care join here Or "to be able to more easily send your refferals to clients could you fill out this form to make sure the inforamtion i have is up to date..." get creative with it... i like waht we have here --> Just would definitely like to adpat it"

CC-27 Joining should recognise people who are already in the system

Status: 🔴 Not started.

What. When someone opens an invitation link, the first thing to ask is their work email. If that email already belongs to someone in the system — because their organization was pre-registered, or a colleague added them — send them a sign-in email right there and skip the rest. If not, start the guided sign-up (CC-28). The same recognition applies when an organization was already registered and a new person from it is just joining.

Done looks like. Open an invite link as an existing person: one field, one email, signed in. Open it as a new person: the guided flow begins.

Drew, 2026-09-17: "ON THEM JOINING! when they get sent the link --> it should ask them to authorize via their work email (your partner org might have already added you" check and see insert work email and if they're in the system send an auth email and streamline onboarding, if not the onboarding link has got to be type form inspired"

CC-28 A guided sign-up where we do the verifying

Status: 🔴 Not started. The biggest joining item.

What. New organizations should not have to onboard themselves field by field — we can often do it faster from what is already public. The flow, one screen at a time, Typeform-style:

1. Email, then a few simple questions.
2. A live introduction to the software — they can look around with partial access, locked until their organization is verified.
3. Verification with three simple checks: their website, their business email domain, and one more easy check.
4. From the website: pull the organization's public details and photos, strip and prepare them, and ask consent to use the live photos and information.
5. A loading screen while we set them up.
6. The user agreement.
7. Then straight into using the features, with a short guided setup.

Done looks like. A new practice goes from link to signed-in, verified, pre-filled organization in one sitting, with consent recorded. Tested with a fresh browser session, not a logged-in one.

Drew, 2026-09-17: "the onboarding link has got to be type form inspired ---> email, simple questions, live introduction to the software (partial software access granted, but locked until their org is authorized (it needs to be varieifed via 1) website 2) business email & somethine else simple (because I don't want each org to have to onbaord all themselves because we can do it quicker sometimes, take website, verify org, verify domain, verify and strip photos and get consent to get live photos and info from their website --> than go through a loading screen -> than have them complete the user agreement, this is similar if an org was already pre registered as well and they're just joining... than after in we want them to utilize the offerings and get set up with the features )"

CC-29 A short introduction to how our nonprofit works

Status: 🔴 Not started. Writing, not code.

What. Make the list of things a new organization needs to understand about how our nonprofit's systems work — what is free, what we ask of them, how referrals move, how their data is handled, who to call — and turn it into the introduction step in CC-28 and a page they can come back to.

Done looks like. A one-page, plain-English introduction, reviewed by Drew, shown during joining and linked from Plan & support.

Drew, 2026-09-17: "more on this... I'd love to streamline their joining process which we need to make a list for so we can easily get new people who join understanding how our nonprofit systems work!"

CC-31 Get ready for Twilio

Status: 🔵 Needs Drew's go-ahead on the plan in Twilio, in plain English below. The detailed plan page is twilio-plan.pages.dev (same passcode as the plan page).

What. One Twilio number for the whole care console: text notifications and two-way texting, turned on per person and per conversation. Email stays the default notice; texting is the upgrade a person chooses. Everything the console needs to be ready — one send function with the safety rules inside it, opt-in by keyword, per-person toggles, a kill switch — is written up on the plan page.

Done looks like. A production Twilio account under the existing login, a registered brand and campaign, one number, and the console sending its first notice to the first opted-in person (Drew).

Drew, 2026-09-17: "another to do list item is to make sure that we are prepped to incorporate twilio into the mix... while i would prefer to skip dev altogether and jump straight to twilio live, i understand dev is beneficial... a section at the bottom should be dedicated to explaining to me in plain english simple 3rd grade english how we will create an entire dev version of the software to run while as create a prod version of the software to the the other twillio acocunt... also which emails should those twilio accounts (one dev and on prod) be using ??? should we create two emails to create the accounts, and how do we get the nonprofit discounts once it's time (see gmail connector to find the email with twilio if needed). on this plan put the link to take action and give me your guess as to how we will get the nonprofit authorized and steps for dev build out a2p for prod and also risks if i skip straight to prod (because I am not scared of doing a2p --> partly beecause i am more scared that when i try to switch from dev twilio to prod twilio it will be a nightmare that i have to test all over again( but than again it sounds like it will be good practice and probably save me headaches when tests new text systems live down the road so we don't get blocked) --> as you've seen in my other plans... our goal is to have one twilio number for text notifications (and two way texting) for the whole care console as is turned on per chat / indiviaul"

CC-32 One shared number with extensions and a call-back voicemail

Status: 🔵 Needs a decision. This re-opens a choice made 2026-09-09, when voice was taken off the plan. Drew is free to re-open it; this item records that he has.

What. Every organization user gets calling through one shared number, each person automatically given an extension. When someone calls out from the console and reaches voicemail, the console speaks a message at the start of the voicemail: "Call back (number) at extension 5671 to connect. Again, that's extension 5671." When the person calls back, the shared number answers, asks for the extension, and routes the call to that user in their browser. Calling is off by default for an organization and switched on deliberately. Safeguards can be added as problems appear.

Done looks like. A design page first (plain English on top), then: one voice-capable number, extensions assigned automatically, browser calling in the console, the voicemail message, and the call-back routing — tested between two real people.

Drew, 2026-09-17: "We will also give every therapy org user (and every org staff user call ability through a shared number where everyone was automatically given an extension and than call back automated voicemail at the beggining of someones voicemail when an org member calls out via the care console it can say ("Call back xyz phone number at extension "5671" to connect, again that's extension "5671" ---> than when the call back it might be good for it to start with just a number routing for extension (and that automated voice message with the extension inserted)... this will allow calling if necessary (and we can put safeguards evntually if we encounter problems)... also many orgs phone calling ability will be off"

CC-33 Can the stricter privacy mode be switched on later? (research)

Status: 🔵 Answered below; Drew decides whether anything follows.

Answer, short. Yes. Twilio offers a stricter privacy mode (what they call HIPAA-eligible) on paid accounts. It is turned on later, on the same production account, by accepting an added agreement and using only the products marked eligible for it. It is a settings-and-paperwork step, not a rebuild. Note that Drew told Twilio in writing on 2026-09-02 that the care-coordination traffic will carry no protected health information, and the console is designed on that basis — so nothing on this list needs it today.

Drew, 2026-09-17: "(another thing to research about twilio is whether or not hippa compliance can be turned on via prod later and if so, how easily or not so easily)"

CC-34 Encouragements and badges — thinking first

Status: 🔵 Brainstorm, not build. Nothing ships until Drew has read the thinking.

What. Conversations, referrals and scheduled calls naturally show who is active. That could power gentle encouragements or badges for clinicians. Drew likes the current structure and wants deep thought before anything is built, because this can easily feel invasive. First thinking is in Badges, first thinking below.

Drew, 2026-09-17: "chats and tools like this can also be used to track activity to give poeple active clinican encouragements or badges(this needs to be thought deeply about as it shouldn't come across invasive so be thoughtful on our badges... as of now i like our structure so lets plan and think and brainstorm on the whole badges system, just things to think about)"

CC-35 liah.cc and what we call ourselves

Status: 🔵 Parked, Drew's decision. The liah.cc zone is live on the LIAH Cloudflare account with no records on it yet (checked 2026-09-17).

What. Should the console's backend — and eventually the whole console — live at liah.cc, with care-co.loveisahabit.org kept and forwarding? "LIAH" is fine as the console's short name; "liah.cc" is short and memorable; liah.org may come later. The open questions are trust (does a two-letter ending read as secure to a practice owner?), what every link in the system needs to change, and what it does to the brand. Thoughts in Branding: liah.cc below.

Done looks like. A decision recorded here with the date. If yes: a list of every address that changes, forwarding from the old address that never breaks, and one practice's links tested end to end.

Drew, 2026-09-17: "(on all of these links we need to think about liah.cc and the brand switch to have the backend live at liah.cc ---> I am not sure what this will do to our branding, I definitely still want forwarding.. I think it's okay for the care console to be called liah slang (eventually i bleieve we'll get the liah.org domain so it might all fit very easiily --> coordinating care liah,org) branding is something to think about... LIAH care console is where Liah.cc comes from liah is loveisahabit. that's also where. Care-co.loveisahabit.org comes bc i wanted the domain to be shorter when i made it and couldn't chose care coordination console or just care console so i took the overlap co... I thought about the domain care.co but that's taken and liah.cc just is so short and nice...liah care console liah.cc www.liah.cc i hope that comes across trustworthy and secure... it might take some getting used to..."

CC-36 Avatar on the right, org mark on the left, and a login page per org

Status: 🔵 Small part ready to build; the subdomain part needs Drew's yes on the recommendation.

What. Three related things about identity in the top bar:

1. The far-right icon in the top bar should be the signed-in person's avatar (photo, or their initials until they upload one). Today both ends show the organization's initials ("KM … KM" in Drew's screenshot), which reads as a bug.
2. The left mark stays the organization's — and organizations should be able to show their logo there instead of initials (optional, from Brand).
3. Eventually each organization gets its own login page, something like kidmatters.liah.cc.

Recommendation on the subdomain question (Drew asked me to decide for the plan). Auto-choose the subdomain from the organization's slug, and let an admin change it once in Brand. Auto-choosing means every organization has a clean address the day they join with nobody typing anything; the one-time edit covers the practice that wants "kidmatters" instead of "kid-matters-counseling". Free text with no default leaves half the network with no page. This depends on CC-35 (liah.cc), so it is sequenced after that decision; the avatar and logo parts are not, and can ship now.

Where. The top bar is built in apps/liah-console/app/shell.js (kcc-topbar); avatar photos already live on the org_staff row (see the Team tool); the logo is brand_logo on the tenant.

Done looks like. Sign in as two different people at the same organization: the right-hand icon differs, the left-hand mark is the same. An org with a logo uploaded sees it on the left.

Drew, 2026-09-17: "another thing i want to add as of now(not in the last message) is that the icon on the far right on the nav bar should be the users avatar logo icon or image (whatever we decide) and the other logo / initials are on the left ( i think it might not hurt to put orgs logos potentially on the care console nav bar as optional too (I think we should eventually consider each org having their own login page like kidsmatter.liah.cc or something like that --> admin could chose their subdomain maybe --> or it can auto chosen for them) --> decide the better option for the plan"

CC-38 Every option under "+" in a chat must actually work

Status: 🔴 Not started. Depends on CC-23 (schedule a call) for one of the five.

What. The "+" beside the message box opens "More you can do here" with five options — Attach a photo or a document, Bring someone in, Get a person, Somewhere to go, in person, Call desk. In Drew's screenshot every one of them is a grey explanation of why it does not work here ("rooms only", "once your rooms account is joined", "hasn't connected a phone system"). None is clickable. Each must either work in this chat or not be listed. In particular:

• Attach a photo or a document — make it work in team and partner chats, not only rooms.
• Bring someone in — add a teammate to the conversation, right here.
• Get a person — reach the LIAH team (ties to CC-39's shared room).
• Somewhere to go, in person — either real (a directory of in-person help) or removed.
• Call desk / coordinate a call — becomes the "schedule a call" helper (CC-23).

Done looks like. Every listed option does something when tapped, tested and verified one by one; an option that cannot work for this organization is not shown, rather than shown greyed.

Drew, 2026-09-17: "ALSO !!! when I click "+" on the chat none of the options are clickable and have been bulit out yet... we need these to work,,, as seen in the second photo each of those + options like coordinating a call helper should all be test, verified and working"

CC-39 Every organization gets a shared room with the LIAH team

Status: 🔴 Not started.

What. The moment an organization joins, it should automatically have one shared room with the LIAH team for feedback and support. These are the LIAH-enabled rooms: they sync to Drew's dashboard and are visible to every LIAH team member, so LIAH can help and manage from one place. While there, the mini-CRM inside LIAH-enabled rooms needs freshening: a list of what is already done in it, and suggestions for what would help.

Where. The Worker's STAFF_FEEDBACK_ROOMS setting already seats LIAH staff in named rooms per org (tests cover it) — the gap is that it is a hand-kept list, not automatic on join, and not every org has one.

Done looks like. Register a fresh test organization: a room with the LIAH team exists before anyone opens Messages, shows up on Drew's dashboard, and every LIAH team member can see it. A short "done / suggested" note on the mini-CRM is added under this item.

Drew, 2026-09-17: "also for now every single org who joins the care console should automatically have a shared room with the liah team for feedback so that liah can help manage and support (this should be synced and show up in Drew's dashboard and visable to all liah team members--> these are liah enabled rooms --> speaking of the mini crm dynamics in the liah enabled rooms needs a freshening up too... completed items her and suggestions would help)..."

CC-40 GHL notification → secure-chat nudge: verify it is done

Status: 🟡 Built and proven for one org; verification for the rest is the open part.

What. When a practice's GHL "remove tag" automation fires the webhook, the console should nudge the person toward their organization's own secure chat widget. What is true today (checked against the runbook and PR #154, merged 2026-09-11): the Worker route /notify/reply receives the webhook, and the console shows the nudge on four surfaces — a green dot on the Messages tab, the header count badge, a count pill on "Open your secure chat", and an "Open / Not now" strip under the header. On 2026-09-11 the GHL workflow was proven to reach the Worker for Kentlands. By design the webhook carries only the clinician's email, so the nudge says "your organization's secure chat has something new", never which conversation.

Still to do. Confirm the GHL workflow is wired for every org that has a chat widget (today that is the one org with a published widget), write the two-field setup (webhook URL + secret) into the admin's Console setup tool so a new practice can connect it without us, and re-test with a fresh session. Runbook: docs/reference/SECURE-CHAT-UNREAD-INDICATOR.md.

Done looks like. A tag removed in a partner practice's GHL lights the nudge in that practice's console within 30 seconds, for a practice other than the first one.

Drew, 2026-09-17: "spealing of messaging features... we talked alot about a plan to have the notifications that come from ghl trigger a relevant notification in the hippa complaint chat widget popup button to guide individuals there when the webhook is triggered via the remove tag automation notification on the care console work around... lets verify this has been done and will get done if it hasn't yet"

CC-30 Take "Try it as Kentlands" out of Plan & support and the disclaimer

Status: ✅ Done 2026-09-17 — PR #174 (merge commit recorded in the next update). The four previews now say "Try it with a sample organization" (the own-org wording gate rejected "sample practice", which is the right call: that word is for the network, not the reader). The playbook's "am I the default org" check reads the tenant's isDefault flag, never the slug; the join page no longer special-cases a slug (it asks the Worker and trusts isDefault); the internal launch page calls the account links "anchor practice" instead of naming it. The gate: npm run check:sample-practice (in the check:core chain, so CI blocks a deploy) scans every console code file, masks comments, and fails on the name; the two scrub rules that must spell it to remove it carry a sample-practice-allow: marker with a reason. Proven non-vacuous: putting the old button label back produced one finding and a failed build. Deliberately left alone: the bundled example call script is Kentlands' real script, shown to other organizations only under an "Example script" banner with the identifying details blanked by the scrub — changing the file would change what Kentlands' own coordinators read. The Worker's DEFAULT_TENANT || 'kentlands' fallback is Worker-side and stays as documented in CLAUDE.md ("read isDefault, never the slug").

What. The Plan & support tab shows four premium previews with a "Try it as Kentlands" button (in apps/liah-console/tools/organization/plan/plan.js). Kentlands is one partner among many and should not be attached to us more than any other practice. Change the previews to a made-up sample practice. While there, keep going: the app shell still treats Kentlands as the default tenant (the one that gets the bundled look when no organization is named), the join page special-cases the slug, and the internal launch page lists Kentlands' account links. Each of those is the same habit.

Done looks like. No visible Kentlands wording anywhere a user can see. No code path where "no organization" silently means "Kentlands". A gate that fails if the wording comes back.

Drew, 2026-09-17: "Also as for the Plan & support page and disclaimer get rid of the try as kentlands language, we do not want kentlands to be attached to us any more than any other practice (we started there, but have to cleanse the codebase accordingly)"

Drew, earlier in September 2026: "we need to verify that the basic color is no longer kentlands orange and all kentlands or clinician conosle or coordinator conole laziness in the code is change and updated and cleansed"

CC-24 Floating save button and an unsaved-changes warning on Edit team member

Status: ✅ Done 2026-09-17 — PR #174 (merge commit recorded in the next update). The Save bar is now sticky at the bottom of the popup at every scroll position, with an "Unsaved changes" note that appears the moment a field differs from what the popup opened with (ticking a box off and back on counts as no change). Cancel, the X, clicking the grey area outside, Escape, and the browser Back button all ask the same question in Drew's words — Save your changes, or leave without saving? — with Keep editing / Leave without saving / Save. Nothing changed → it just closes. The bar lives inside the scrolling popup, so it never covers the last field; on a phone it rises by the on-screen keyboard's height and clears the home bar. The shared modal helper gained a beforeClose hook so any other popup can veto Back the same way. Five tests; proven non-vacuous by wiring Cancel back to the old close (one test fails). Who else this touches: every organization's Team screen, identically; no data or permission change.

What. The Edit team member popup on the Team tab is long. Add a floating Save button pinned to the bottom-right so it is always in reach. Auto-save would be annoying at this length, so instead: if someone has changed something and clicks away, ask them once — Save your changes, or leave without saving? Think about the small things: the button should not cover the last field; on a phone it should sit above the keyboard; Escape should trigger the same question.

Where. The popup and its save-member action live in the roster tool (apps/liah-console/tools/organization/roster/roster.js). Closing the popup today does not check for unsaved edits.

Done looks like. The floating Save is visible at every scroll position on phone and desktop. Changing a field and clicking outside asks the question; saving or discarding both work; closing with nothing changed asks nothing.

Drew, 2026-09-17: "ALSO on the edit team member popup on the team tab i think we should have a floating save button in the bottom right corner (auto save might be annoying with how long some of the things are), we just need a warning if they made changes and go to click out that prompts them to save or not save... I think that's a good ui ux fix for that particular functionality... think about it and optimize!"

CC-21 Fix the "connect a chat widget" message for people who can't do it

Status: ✅ Done 2026-09-17 — PR #173, merged as 998333e. Checked in code and in the Messages screen test with a clinician-only role set: the set-up button was already admin-only (Drew saw it because he is an admin everywhere). What changed is the sentence everyone else reads, now in Drew's words: "Nothing connected yet. Ask your admin to set up the covered chat. Until then, use the chat below for anything that is not client detail." No button for non-admins; the admin branch is unchanged. Two tests, one on the card and one on the full Messages screen as a clinician, both proven to fail against the old wording.

What. When an organization has no covered chat connected, the Messages tab invites the reader to connect one. Clinicians and coordinators cannot do that — only an admin or owner can. For everyone who is not an admin, the message should say something like: ask your admin to set up the covered chat, or just use the chat below for anything that is not client detail.

Where. The card is built in the console's chat-surface module (the protected-channel card in apps/liah-console/app/chatsurface.js) and shown from the Messages tool. The code already has an admin and a non-admin branch; check what a real clinician login actually sees, because Drew saw the invitation.

Done looks like. A clinician login sees the "ask your admin" wording, never a set-up button. An admin still sees the set-up button. Covered by a test.

Drew, 2026-09-17: "also on the fact the message tab for a practice with no hippa compliant chat widget it still invites clinicians and coordinators to "connect a chat widget" --> they couldn't do that anyway... that is the admins job or the owner and so we need to change the tab if a widget doesn't exist yet to allow it to say something else that they can ask their admin to set up the hippa complaint chat or just use the non phi chat below (something like that will help)"

CC-05 The call-script button should not be on the clinician home page

Status: ✅ Done 2026-09-17 — PR #173, merged as 998333e. The cause: the call script was granted to the admin role as well as coordinators, so an owner who also sees clients landed on the clinician home with a Script tab on the bottom bar beside their availability. A pure clinician never had it. Now the call script (and the Cockpit and Care & support panels folded into it) belong to the coordinator role only; someone who takes calls and also runs the organization holds both roles on their staff row, which the Team screen sets. Admins keep the call-script editor under Organization. Covered by a new test that fails if any role set without coordinator gets the script back (proven: restoring admin fails 2 of its 3 tests). Who else this touches: every admin on the network who does not hold the coordinator role loses the Script tab; if one of them actually takes calls, add coordinator to their row.

What. A clinician's home page shows a call-script button. Clinicians do not take coordination calls; that button belongs to coordinators. Find what decides to show it and stop it showing for clinicians.

Done looks like. A clinician-only login never sees the call-script button on its home page. A coordinator still does. Covered by a test that fails if the button comes back.

Drew, 2026-09-17: "Also why does on the clinician tab the call script. button pop up on the homepage... that needs to be corrected"

CC-08 Bring back the call-note popup that sits above the bottom bar

Status: ✅ Done 2026-09-17 — PR #172, merged as 01befd9, CI run 35300833222 green including the plan-page publish, live STAMP 20260917.86470f64 (probed: the live script module carries the panel buttons and the sheet rule; the registry rows carry their redirects), committed to a branch from the first edit and pushed, as this item asks. On phones and narrow windows the open call note is now a sheet fixed along the bottom edge, sitting just above the bottom navigation bar, with the script padded so its last step stays reachable and the Script/Note handle riding the sheet's top edge. Opening it no longer scrolls the page. What was typed stays through step moves, organization switches and navigation. No screenshot in the PR: the test login needs a credential typed, which the assistant does not do; live verification is recorded below after merge.

What. The call note should be a popup that sits just behind the bottom navigation bar, exactly like the old Kentlands coordinator console. It stays open while you move through the script. Notes are easy to read and easy to move through, and the note follows the call as it moves from our own organization, to a partner organization, to another organization. Study the old console before building — it is the reference.

Done looks like. Open the call script, start a call, and the note popup is there above the bottom bar. Move through steps, switch to a partner organization, come back — the note is still there with everything typed. Verified live, with a screenshot in the pull request.

Why it has failed before. Twice this was built and the edits did not persist. Whoever takes this: commit to a branch early, push often, and merge — do not leave it in a working tree.

Drew, 2026-09-17: "we also have already made all these updates on the call script to allow the call note to be a popup that sits behind the bottom nav bar (just like the old kentpsych coordinator console, which you can view), it also had an easy ui/ux beautiful easy to navigate notes situation and easiely went from our org, to partner org to another org (I AM SO FRUSTRATED BC IVE ALREADY UPDATED THIS TWICE BUT THE EDITS DIDN'T SAVE FOR SOME REASON)... this is why the to do list and making sure everything is updated is so crucial"

Drew, 2026-09-17: "the call note pop up was so smooth on the old coordinator console... i loved it..."

CC-07 Combine Cockpit and Care & support into the call script tab

Status: ✅ Done 2026-09-17 — PR #172, merged as 01befd9, CI run 35300833222 green including the plan-page publish, live STAMP 20260917.86470f64 (probed: the live script module carries the panel buttons and the sheet rule; the registry rows carry their redirects). One "Call script" destination under Coordinate. Cockpit (press O) and Care & support (press S) open from the script's own top bar as panels, each running the tool's real code inside; the old addresses redirect into the script with that panel already open, so bookmarks and the onboarding step still land right. Inside the script the cockpit drops its own "Call script" tab and lands on Saved notes. Nothing a coordinator could do before is lost. Verified by npm run check (845 tests) and a new test file proven to fail when any of the four halves is removed; live verification recorded below after merge.

What. Three tabs — Call script, Cockpit, Care & support — should become one tab. Everything a coordinator reaches for during a call should be reachable from inside the script, without leaving it. The other two tabs' content can sit along the top of the script tab, or the bottom bar can change shape when the script is open and become a script-specific bar. Start by combining; polish the layout after.

Done looks like. One "Call script" destination under Coordinate. The Cockpit's tools and Care & support's content open from inside it. The two old destinations redirect to it so old links keep working. Nothing a coordinator could do before is lost.

Drew, 2026-09-17: "Finally the cockpit tools should all be accessible in the call script, we can fully put the cockpit accessible in the script tab and remove the script tab... maybe only for the script tab when we open the script tab the bottom nav bar transforms into a full section and a new adapted script experince bottom nav bar appears (the first goal is to COMBINE cut the Cockpit and the care and support tab place it into the script tab --> combine all three into one script tab(the two other tabs content can be on the top nav bar of the script tab or something"

CC-37 The "Latest" pill in Messages never goes away

Status: ✅ Done 2026-09-17 — PR #171, merged as f97f853, CI run 35298868505 green including the plan-page publish, live STAMP 20260917.0303461c. The pill now shows only when the transcript is laid out, has messages, actually overflows, and the reader is off its foot; its state is recomputed on every paint. Three new tests, proven to fail with the old rule restored (the empty-thread case is exactly Drew's screenshot). Verified live: an empty conversation shows no pill.

What. The floating "Latest ⌄" pill above the message box (built as plan item F26, the "jump to latest" button in apps/liah-console/tools/network/inbox/inbox.js) is meant to appear only when you have scrolled up and newer messages are below. In Drew's screenshot it shows in an empty conversation, and it does not disappear. Fix: hide it whenever the view is already at the bottom or the thread has nothing to jump to; show it only when there is somewhere to jump. Then walk the rest of the conversation view with the same eye (send states, the read tick, the empty state) and tune what is half-built.

The rule Drew set. Anything added to Messages has to be finished quality — working, relevant, and tested with real sends — before it ships. A floating control that lies is worse than none.

Done looks like. Open an empty thread: no pill. Send three messages: no pill. Scroll up in a long thread: pill appears; tap it or reach the bottom: pill disappears. Checked in a fresh session on phone and desktop widths.

Drew, 2026-09-17: "Also another new thing as seen in the image their is a latest floating icon above the messaging box... that's fine to have but it needs to be relevant and work...IT WON:T DISAPPEAR !! SUPER ANNOYING, if we're going to make any updates like this it needs to be quality... no messages have been sent so we need to fine tune and develop this feature (and any other helpful messaging features)"

CC-02 Remove the "Our list" tab everywhere

Status: ✅ Done 2026-09-17 — PR #171, merged as f97f853, CI run 35298868505 green including the plan-page publish, live STAMP 20260917.0303461c. Removed from Kid Matters and Kentlands (their repositories and the console's copies); TeachCreate's owner had already replaced it with a real TeachCreate tab, which landed in the console the same evening (PR #167, SDK 1.1 apps.connected()). The scaffold no longer creates it for new organizations — a new repository starts with no tabs and the worked example lives in scripts/core-example-tab.js. Verified: check:verticals passes with the directories gone, and live: no "Our lists" tab for those admins.

What. The "Our list" tab adds nothing. Remove it from every place it appears: the registry, the navigation, any home-page shortcuts, any deep links, and the tests that reference it. If it holds any saved data, say so in the pull request before deleting it.

Done looks like. No trace of the tab in the console or the code. npm run check green.

Drew, 2026-09-17: "Our list tab --> worthless and should be removed everywhere"

CC-01 The therapy finder should be a widget, not its own tab

Status: ✅ Done 2026-09-17 — PR #171, merged as f97f853, CI run 35298868505 green including the plan-page publish, live STAMP 20260917.0303461c. The finder is now a card on Organization → Website widgets for Kid Matters, mounted inside its own "Customize widget" panel; the standalone tab is gone. Built as a general seam, not a one-off: any organization's repository can mark a tool "surface": "widget" and it becomes a card there instead of a tab. Verified: composition test (the entry never enters the navigation) and live at care-co.loveisahabit.org as a Kid Matters admin.

What. The console still shows the therapy finder as a tab of its own. It was supposed to live as one of the widgets on Organization → Website widgets, next to the others, with its own "Customize widget" panel. The tab should go; the widget should stay (it already exists and is live).

Done looks like. No standalone therapy-finder destination in the tool registry or the navigation. The finder appears only as a widget on the Website widgets tab. Nothing an organization saved is lost.

Drew, 2026-09-17: "already mentioned but incomplete --> the therapist finding tab still exists as it's own tab, when the code was supposed to be placed as one of the widgets on the widgets tab"

Drew, earlier in September 2026: "there is an entire tab called (The therapy finder …) and that should be added to the website widgets page and synced in so that as availability is updated it is all synced accodingly"