Skip to content
Baseworks KB

Asia's Inbox

Created 2026-03-03
Updated 2026-03-19
Tags inboxasiaworkflow

Review queue. Items are added by Claude when something needs your attention. Mark done [x] and note any decisions.

See 1 for how this works.

Open Items

Section titled “Open Items”

[x] 2026-04-20 21:32 ET | Build Formidable Form 67 → FluentCRM custom-field hook

Section titled “[x] 2026-04-20 21:32 ET | Build Formidable Form 67 → FluentCRM custom-field hook”

Added by Claude Code on Patrick’s Mac

Context

Section titled “Context”

Prerequisite for the new Participant Support Layer (see 03-resources/plans/participant-support-layer-plan.md, section “Tier 1 prerequisite build tasks”, item 2). The support layer’s segment-acknowledgement flow and every future segment-triggered automation depend on this hook.

Decision made during planning: rather than create one WP-Fusion tag per Primer segment, capture segment completion as a single FluentCRM custom field that updates on every Form 67 submission. One code path, one source of truth, FluentCRM automations read from it.

What’s needed from you

Section titled “What’s needed from you”

Small mu-plugin or snippet on practice.baseworks.com:

  • Hook: frm_after_create_entry, filtered to Form 67 (Segment Feedback).
  • Read the segment-name field from the submitted entry.
  • Look up the submitting user’s FluentCRM contact by email.
  • Update two custom fields on that contact via FluentCRM’s internal API:
    • last_segment_completed — slug/name of the segment just submitted.
    • last_segment_completed_at — submission timestamp.

Where it lives in the repo: baseworks-changelog under sites/practice.baseworks.com/. Whichever folder matches the existing pattern for small hook-snippets (mu-plugins or plugin-settings-code).

Why it matters

Section titled “Why it matters”

This is the first of two plumbing pieces that unlock Tier 1 of the support layer. The other piece (adding do_action('bw_activity_logged') to the Activity Plugin) is Patrick’s. Once both land, all Tier 1 flows can be built.

Section titled “Related”

[ ] 2026-04-18 20:45 ET | Widen trigger-tag list on FluentCRM automation #42

Section titled “[ ] 2026-04-18 20:45 ET | Widen trigger-tag list on FluentCRM automation #42”

Added by Claude Code on Patrick’s Mac

Context

Section titled “Context”

A new automation “People aggregator — webhook on CRM change” (id 42) is live in FluentCRM. On every tag application it POSTs to https://agents.baseworks.com/webhook/people-index, which re-runs the vault’s people aggregator with fresh CRM data. This gives the vault near-real-time visibility into contact changes instead of waiting for the 4-hour cron.

Patrick published it with a conservative starter scope — only two tags currently trigger the automation:

  • Tokyo Studio Alumni (tag id 103)
  • Event: Practice Meet Tokyo (tag id 74)

What’s needed from you

Section titled “What’s needed from you”

Open the automation and widen the trigger tag list to cover every tag whose application should cause a vault re-sync. Candidates to consider:

  • Tags that affect entry-path in the aggregator (study-group cohorts, practice-community, teacher-training variants)
  • Tags you set during CRM cleanup / categorization work
  • Lead-Background, Movement-Industry, Lead-Source tag families

You probably know the full landscape better than the aggregator does — trust your judgement, err on the side of more tags, since each trigger is cheap (the receiver coalesces bursts).

Where to find it

Section titled “Where to find it”

crm.baseworks.com/wp-admin/admin.php?page=fluentcrm-admin#/funnels/42/edit → click the trigger block at the top → add tags → save.

Also worth considering

Section titled “Also worth considering”

The automation only triggers on tag applications. If you want custom-field updates (e.g. changes to romaji_name, yjat, pb_primer_deadline) to also fire the webhook, add a second trigger of type “Contact Custom Data Updated” pointing to the field you care about. Each field needs its own trigger row; not a single one covering all fields.

Background

Section titled “Background”

Full setup doc: people-webhook-setup in 03-resources/vault-and-tooling/.

[ ] 2026-04-18 19:45 ET | New FluentCRM custom field: “Romaji name” — populated for 65 contacts

Section titled “[ ] 2026-04-18 19:45 ET | New FluentCRM custom field: “Romaji name” — populated for 65 contacts”

Added by Claude Code on Patrick’s Mac

What’s new

Section titled “What’s new”

A new contact custom field has been added to FluentCRM on crm.baseworks.com:

  • Label: Romaji name
  • Slug: romaji_name
  • Type: text

It has been pre-populated for every subscriber whose first_name or last_name contains non-ASCII characters — 65 contacts total:

  • 9 diacritic-bearing Western names (e.g. Noémie Normandin → Noemie Normandin, Véronique Pelletier → Veronique Pelletier, Zulma Gámez → Zulma Gamez). Simple NFD strip throughout — no German oe/ae/ue conversion applied.
  • 56 Japanese-named contacts — Hepburn romanization without macrons, Western order (Given Family). Each romanization was reviewed and approved by Patrick against the kanji + any email-address hints. Where the CRM had family-name-in-first-name-field (e.g. id 291 福田/桃子, id 332 品川/隼人), the romaji field rebuilds the Western-convention order.

Why this exists

Section titled “Why this exists”

The vault’s people aggregator builds file slugs from each person’s display name. Japanese (and some diacritic-heavy) names produce unusable slugs — the current MOC at 02-areas/people/index.md has five broken-looking wikilinks like [奈美 熊谷](/unknown/) as a result. With the romaji field populated in CRM, the aggregator can pull it via the existing CRM-tag reader in scripts/people_remote.py and use it to generate clean ASCII slugs (nami-kumagai.md instead of a “unknown” fallback). It also gives you a searchable ASCII handle inside FluentCRM’s contact filters.

What you can do with it

Section titled “What you can do with it”
  • Filter/search subscribers by romaji in FluentCRM admin.
  • Use the field as a merge tag in email campaigns if useful (e.g. for romaji-friendly greetings in bilingual newsletters).
  • Correct any romanization you disagree with directly in the contact’s profile — the aggregator will pick up changes on its next cron run.

Infrastructure notes

Section titled “Infrastructure notes”
  • Pre-change CRM DB dump (29 MB) is safely in B2 at b2://cbcrmbaseworks/crm-baseworks-web/adhoc-backups/crm-pre-romaji-field-20260418-193559.sql.
  • No schema/DDL changes were needed. The field definition is a row in 3ZGRM_fc_meta; values are rows in 3ZGRM_fc_subscriber_meta with key='romaji_name'. Fully reversible with a single DELETE if you ever want to undo.
  • Changelog entry: ~/Documents/baseworks-changelog/CHANGELOG.md 2026-04-18.

Next step (optional, not done yet)

Section titled “Next step (optional, not done yet)”

Wiring build-people-index.py to consume romaji_name for slug generation is the natural follow-up. Let Patrick know if you’d like that done now, or leave for a future session.

[ ] 2026-04-18 18:25 ET | URGENT (only if you pulled between 18:02 and 18:20 ET): changelog repo history was rewritten

Section titled “[ ] 2026-04-18 18:25 ET | URGENT (only if you pulled between 18:02 and 18:20 ET): changelog repo history was rewritten”

Added by Claude Code on Patrick’s Mac

What happened

Section titled “What happened”

A commit I made at 18:02 ET (1036717 Step 1: Primer Form 66/67 export plugin) accidentally included ~4,000 files of node_modules/ content from sites/baseworks.com/mockups/ that should have been gitignored. To keep the repo lean, I force-pushed a clean replacement commit (bb65a15) at 18:20 ET. The intended content (a new mu-plugin for Primer forms + SSH docs updates + tightened .gitignore) is in the clean commit.

Do you need to do anything?

Section titled “Do you need to do anything?”

Only if you did git pull in the ~/Documents/baseworks-changelog/ repo between roughly 18:02 and 18:20 ET on 2026-04-18. Outside that window there’s nothing to do — your next git pull will just fetch the clean history.

If you’re not sure, run this in Claude Code (or paste it to ChatGPT/Claude Desktop with the directory open):

Terminal window
cd ~/Documents/baseworks-changelog && git log --oneline -5

If you see 1036717 Step 1: Primer Form 66/67 export plugin anywhere in that list, you pulled the bad commit. Fix it by running:

Terminal window
cd ~/Documents/baseworks-changelog
git fetch origin
git reset --hard origin/main

That discards the local bad commit and resets to the cleaned-up remote. No data loss — you had no uncommitted work in this repo, right? If you did have uncommitted changes, stash first (git stash) then reset, then git stash pop.

If 1036717 is NOT in your log, do nothing — you’re already clean.

Why you’re being told

Section titled “Why you’re being told”

Per our Git Safety Protocol, force-pushing to main is a thing we don’t do casually. I checked the VPS (clean, many commits behind, no problem there) but I can’t verify your machines from here, so this note is the belt-and-suspenders check. Sorry for the jitter.

[ ] 2026-04-18 18:08 ET | Session 3 Summary ready for review

Section titled “[ ] 2026-04-18 18:08 ET | Session 3 Summary ready for review”

Added by Claude Code on Patrick’s Mac

The English draft of the Session 3 summary (April 18) is ready for your review.

What’s in it

Section titled “What’s in it”
  • Forms covered: Star Form (review), Star Tilt (review), Front Lunge Extension (review + rib-cage lift), Front Lunge Torsion (new), V-Sit (new), Simple Cross Inflection (review with micro-movements added), Square Cross Inflection (new), Peak Hold (brief review)
  • Key concepts: FSA in the Lunge Extension, the byproduct principle (V-Sit shoulder lead, pelvic floor discussion), intensity modification with micro-movements (from James’s hip question), Structure focus, NODAA methodology (from Marta’s question about hands-on)
  • Q&A: Elinor (pelvic floor), James (hip discomfort), Marta (NODAA / private sessions), Noémie (byproduct terminology + spatial sensation), Natalie (daily practice)
  • Voice: “we” default, first person for Patrick where named. Winter-summary density target applied to form sections
  • Resources section now includes a link to the Key Teaching Principles page plus two subsections for the upcoming Brenda Milner Day (May 11, McGill — Eventbrite registration link) and BRNet 2026 in Padova (June — baseworks.com event link)
  • Next Assignment is Segment 4, ~87 min

Not covered in the session (carry-forward for Session 4 prep)

Section titled “Not covered in the session (carry-forward for Session 4 prep)”
  • Squat (not practiced at all today)
  • Seated Wide Inflection and Seated Inflection (from the plan, ran out of time)

Version tracking — new standard in place

Section titled “Version tracking — new standard in place”

Patrick has asked that we start tracking revision history on session summaries, blog posts, and (eventually) platform lesson summaries. A standard has been written at Document Revision Standard in 03-resources/vault-and-tooling/, with Session 2’s Editorial Notes as the reference implementation. The /session-summary and /write-blog-post skills have both been updated to reference it.

When you review Session 3, please append a ### Round 1 revision (2026-04-18) sub-heading under the existing Editorial Notes line and log your changes there (structural / content / corrections / notes-for-future-work). If I or Patrick edit after you, we’ll add Round 2 below yours. Prior rounds are never deleted.

[ ] 2026-04-18 17:45 ET | People aggregator Step 2.5 complete — CRM tags now flow in automatically

Section titled “[ ] 2026-04-18 17:45 ET | People aggregator Step 2.5 complete — CRM tags now flow in automatically”

Added by Claude Code on Patrick’s Mac

What landed

Section titled “What landed”

The people-profiles aggregator (scripts/build-people-index.py) now pulls remote data on every run and folds it into 02-areas/people/. Your CRM tagging pass is wired in as one of the inputs.

  • Admin exclusion: Patrick, you, and vendor accounts (brettforge, woologin, etc.) are no longer generated as person files. Configured in 02-areas/people/_admin-exclude.yml.
  • wp_users join (both sites): emails, display names, user logins, and registration dates are filled in on all 17 person files that had a practice or baseworks user_id. First-name-only records (clementine, dawson, magali, mimi, elinor) collapsed into their full-name counterparts automatically.
  • wp_bw_activity tier: 19 files now classified active, 47 still unknown (mostly Open Day attendees who never registered — those become inquiry once the contact-form source is wired in).
  • Fluent CRM reader: pulls tags + custom fields from crm.baseworks.com for 500 tagged subscribers. The mapping file 02-areas/people/_crm-tag-mapping.yml translates your tag titles to entry-path values. Your Tokyo Studio Alumni (tag 103) mapping and YJAT=Yes → teacher-training-graduate custom-field rule are seeded.
  • BuddyBoss groups: current-programs now reflects Primer Community, Practice Community, and both Montreal Study Group cohorts.

What you can do

Section titled “What you can do”
  • Keep tagging in Fluent CRM as normal. Tags flow into person files on the next run (cache TTL is 1 hour; --force-remote refreshes on demand).
  • If you want new tag titles to drive entry-path, add them to _crm-tag-mapping.yml using the tag title as the key. Example: 
    tag_to_entry_path:
      "Tokyo Studio Alumni": tokyo-studio-alumni
      "TT Graduate 2019": teacher-training-graduate
  • The CRM has 85 subscribers tagged “Tokyo Studio Alumni” and 22 with YJAT=Yes. None of them currently overlap with vault-side person files because Tokyo alumni haven’t engaged through forum/DMs — they’ll get person files once the Step 5 TT-graduate batch import runs, or if any of them interact through the practice site.

What’s next (no action needed from you)

Section titled “What’s next (no action needed from you)”
  • Step 3 is the cron integration so this runs automatically after the forum sync.
  • Step 1 is the Formidable Primer-segment exports (Patrick owes form IDs).
  • Step 5 is the TT-graduate batch import.

Full plan: people-profiles-aggregation-plan — Step 2.5 section now marked complete.

[ ] 2026-04-17 11:00 ET | WPRUS admin account overwrite incident — security fix needed

Section titled “[ ] 2026-04-17 11:00 ET | WPRUS admin account overwrite incident — security fix needed”

Added by Claude Code on Asia’s Mac Mini

What happened

Section titled “What happened”

Today you registered a test account asia@cevaco.co on baseworks.com. WPRUS matched the username asia on baseworks.com to the asia admin account on practice.baseworks.com and synced the email over, locking you out of practice. The plugin was temporarily deactivated on both sites, the email was restored via WP-CLI, the stray user (ID 564, role customer) was deleted from baseworks.com, and the plugin was re-enabled. Access is restored.

Root cause

Section titled “Root cause”

WPRUS matches users by user_login (username), not email. The asia username exists on both sites. With no role filters configured, any public user who registers on either site with a username matching an admin on the other site can trigger an overwrite of that admin’s data.

Fix needed — two-part

Section titled “Fix needed — two-part”

See Patrick’s inbox for discussion. Decisions needed before implementing:

  1. Role filtering in WPRUS — set outgoing_roles and incoming_roles on both sites to only sync subscriber/customer. This prevents any admin account from being touched by the sync, regardless of username collisions.

  2. Rename the asia admin username on practice from asia to pandasia (matching baseworks.com). This eliminates the username collision entirely and is the cleaner long-term fix.

Prior history

Section titled “Prior history”

This is a pattern — see baseworks-changelog/docs/STAGING-USER-SYNC-ISSUE.md (Jan 2026) and sites/practice.baseworks.com/staging-setup-checklist.md. The staging checklist already deactivates WPRUS after every staging push for exactly this reason. The live site pair (baseworks.com ↔ practice.baseworks.com) has no equivalent protection yet.

[ ] 2026-04-17 09:49 ET | Questionnaire export plugins now emit user_login — plus new code-location rules

Section titled “[ ] 2026-04-17 09:49 ET | Questionnaire export plugins now emit user_login — plus new code-location rules”

Added by Claude Code on Patrick’s Mac

Heads-up so you know what changed in the changelog repo and vault today.

What was done

Section titled “What was done”

  1. Added user_id, user_login, and profile_url to questionnaire exports on both sites:

    • sites/baseworks.com/mu-plugins/bw-questionnaire-export-cli.php (Form 40)
    • sites/practice.baseworks.com/mu-plugins/bw-questionnaire-export-cli.php (Form 74)
    • Logic: look up the Formidable entry’s user_id, fall back to email if empty. When a WordPress user is found, three new frontmatter fields get written into the 02-areas/method-admin/audience/event-participants/*.md files. Absent users → fields stay absent and the skill falls back to first name.
    • Purpose: so the /session-summary skill can rewrite participant first names as BuddyBoss @mentions (e.g. @caitlin_b) in group posts, making forum links click-through instead of plain text. Patrick’s inbox item from 2026-04-13 has the full rationale.

  2. Mirrored the practice plugin into the repo. It had been living only on the server (/var/www/practice.baseworks.com/wp-content/mu-plugins/) with no local copy. It’s now committed at sites/practice.baseworks.com/mu-plugins/bw-questionnaire-export-cli.php. Deployed the modified version back to the server with sudo cp; md5 matches.

  3. Added two new code-location rules to prevent this kind of drift going forward:

    • CLAUDE-INSTRUCTIONS.md in baseworks-changelog now has a §3 Mirror-From-Server Checklist: whenever we edit a plugin/snippet/config directly on a server, the final file must be scp-ed back to this repo and committed.
    • The vault’s CLAUDE.md now has a new “Code Belongs in the Changelog Repo” section saying site code must live in baseworks-changelog, not here. Vault-native scripts (sync, wikilink check, agent system) are still fine where they are.

Backups

Section titled “Backups”
  • DB backup of practice.baseworks.com taken before deploy: practice-pre-user-login-plugin-20260417-094631.sql (538 MB), uploaded to B2 bucket cbbpracticesite under practice-baseworks-web/adhoc-backups/.
  • Plugin file backup on server: /tmp/bw-questionnaire-export-cli-practice-backup-20260417-094639.php.

Action for you

Section titled “Action for you”

Nothing urgent. If you pick up work on the /session-summary skill next, Patrick’s inbox item explains the Pre-Flight map lookup and Phase 4 mention rewrite — the data is now in place for that. If you do server-side plugin edits on any site, please follow the new mirror-from-server checklist.

Commits (main, baseworks-changelog)

Section titled “Commits (main, baseworks-changelog)”
  • c6f04c0 Add user_login/user_id/profile_url to Form 40 questionnaire export
  • e3e89b9 Mirror bw-questionnaire-export-cli.php baseline from practice.baseworks.com
  • cf2c895 Apply user_login additive change to Form 74 plugin + doc rule

2026-04-16

Section titled “2026-04-16”

[ ] 10:15 ET | People Profiles (Phase 2) — full plan drafted, ready for your review

Section titled “[ ] 10:15 ET | People Profiles (Phase 2) — full plan drafted, ready for your review”

Added by Claude Code on Patrick’s Mac

The Phase 2 plan for the people-profiles aggregation layer has been drafted at people-profiles-aggregation-plan. This builds on the Phase 1 community-forums consolidation (completed 2026-04-14) and creates a person-scoped layer in the vault — one file per person linking to their DMs, forum posts, questionnaire responses, session appearances, and event participation.

Key decisions made with Patrick today:

  • One-way sync only (CRM/platform → vault, never pushback)
  • All data committed to git (matching current practice; no new gitignored tier)
  • Auto-grow with tiers: every unique email gets a person file, labeled active/past/inquiry/mention
  • Entry-path field tracks how someone first connected (Tokyo studio, TT graduate, Primer, study group, etc.)
  • Registration-date cutoff for Tokyo alumni heuristic: pre-2024-11-01 (see the registration timeline inbox item below for the data)
  • Historical backfill: aggregate everything already in the vault (DMs back to 2021); TT graduates without platform accounts are a separate batch import

What we’d like from you: Read the plan and flag anything that doesn’t match your understanding — especially the entry-path categories, the tier definitions, and the privacy approach. No implementation has started yet.

[ ] 09:30 ET | People Profiles (Phase 2) — registration timeline for your review

Section titled “[ ] 09:30 ET | People Profiles (Phase 2) — registration timeline for your review”

Added by Claude Code on Patrick’s Mac

Context: Phase 2 planning is underway for the people-profiles aggregation layer. One key design decision is the entry-path field on each person file — how someone first connected with Baseworks. To set the automated cutoff between “pre-existing network” and “current enrollment pipeline,” we pulled a registration-date histogram from practice.baseworks.com. Patrick wants you to see this breakdown and flag anything that looks wrong.

Registration timeline (practice.baseworks.com user_registered):

2016-03 to 2018-09:    8 users   — platform inception / testing
2020-02 to 2020-10:    5 users   — pandemic era
2021-03 to 2021-12:   22 users   — biggest early wave (likely TT + Tokyo alumni onboarding)
2022-02 to 2022-11:    9 users   — trickle (existing network)
2023-02 to 2023-11:    9 users   — trickle
2024-02 to 2024-07:   10 users   — gradual pickup
2024-10:                2 users
2024-11:              42 users   — SPIKE (Open Day / Primer launch)
2024-12:              20 users
2025-01 to 2025-12:   26 users   — steady enrollment
2026-01 to 2026-04:   58 users   — Spring cohort + continued growth
                     ___________
                     ~221 total users

The pattern — two distinct eras:

  • Pre-November 2024 (~65 users): Low and steady, never more than 8 registrations in a month. These are the pre-existing network — Tokyo studio alumni, teacher-training graduates, early testers, people who found Baseworks through direct outreach or word of mouth.
  • November 2024 onward (~156 users): Driven by the Open Day / Primer / Study Group enrollment pipeline. 42 registrations in November 2024 alone marked the inflection point.

Proposed automated cutoff: user_registered before 2024-11-01 defaults to tokyo-studio-alumni entry-path (unless a teacher-training graduate list or manual override says otherwise). Users from 2024-11-01 forward fall through to group membership, Primer enrollment, or CRM tags for entry-path derivation.

What we’d like from you: Does this breakdown match your understanding of the user base history? Are there any people in the pre-November-2024 group who you know came through a different pathway (not Tokyo studio or teacher training)? Any corrections or additions to the entry-path categories?

Full plan: [people-profiles-aggregation-plan](/resources/executed-plans/people-profiles-aggregation-plan/) (being drafted now, will be committed shortly).

2026-04-14

Section titled “2026-04-14”

[ ] 12:45 ET | Your SSH access to baseworks-n8n was restored + vault capture pipeline fixed

Section titled “[ ] 12:45 ET | Your SSH access to baseworks-n8n was restored + vault capture pipeline fixed”

Added by Claude Code on Patrick’s Mac

Why you’re getting this: between 2026-04-05 and today, your SSH keys (both Mac Mini and MacBook Air) were silently missing from ~patrick/.ssh/authorized_keys on baseworks-n8n. If you had tried to ssh baseworks-n8n during that window it would have failed. Everything is restored now — you should have no issues SSH-ing to either VPS from either of your Macs. You don’t need to do anything unless you notice problems.

What happened (short version): Patrick’s morning Slack post to #vault-inbox didn’t land this morning. Investigation found that on 2026-04-05 at 03:23:52 UTC, some unidentified provisioning-style operation wiped ~patrick/.ssh/authorized_keys on both VPSes simultaneously, dropping the machine-to-machine keys that the vault capture pipeline and the n8n daily backup depend on. Your two keys on the n8n VPS were also collateral damage in the same event. The n8n daily backup had been failing silently for 10 days, and the daily infra report had been flagging false-positive “Claude CLI authentication failed” warnings for 4 weeks that masked what was actually broken.

What was fixed today:

  • All missing SSH keys restored on both VPSes (including yours on n8n)
  • n8n daily backup ran manually — first successful in 10 days
  • n8n workflow patched to skip Slack message edits (they were producing empty “File: “ / Tags: / From: unknown” vault capture confirmations)
  • Claude OAuth token moved to a single source-of-truth file at ~/.config/baseworks/claude-token on baseworks-agents — the 4-week-old false-positive auth warning is gone
  • A new daily authorized_keys integrity check was added to daily-infra-updates.sh (Test 5) — if any key goes missing again on either VPS, it will show up in both Patrick’s inbox report and #agent-alerts in Slack within 24 hours instead of silently breaking for 9+ days

Where the full record lives:

  • Shared context doc: claude-code-shared-context.md — full write-up under “Recent Infrastructure Changes → 2026-04-14”, plus a new “SSH Key Canonical Lists” section with fingerprint tables for both VPSes and instructions for adding/rotating machines
  • Site changelog: ~/Documents/baseworks-changelog/CHANGELOG.md (repo p-oancia/baseworks-changelog, commit b2391fa) — the long-form narrative with root causes, forensic dead-ends, and end-to-end verification

Mystery that remains: whatever wiped the keys on 2026-04-05 is still unidentified. No trace in auth.log (rotated), systemd journal (volatile), bash history, cron, or reboot records. Signature matches a provisioning-style script run from a control node. If you remember doing anything on your Mac Mini or MBA around Saturday evening 2026-04-04 that might have touched user accounts or SSH configs on both VPSes, please mention it — but no worries if not, the new integrity monitor will catch it within 24h if it ever happens again.

No action needed from you unless something doesn’t work.

2026-04-13

Section titled “2026-04-13”

[ ] 09:50 ET | Spring 2026 Session 2 summary posted, voice/tone refinements applied

Section titled “[ ] 09:50 ET | Spring 2026 Session 2 summary posted, voice/tone refinements applied”

Added by Claude Code on Patrick’s Mac

What: Patrick reviewed and posted the Spring 2026 Session 2 summary today. The forum post is live at https://practice.baseworks.com/groups/montreal-study-group-spring-2026-cohort/forum/discussion/session-2-summary-trajectory-converge-ascend/#post-22210. Patrick will repost it after the latest round of edits has been merged.

Voice and convention refinements made during the review (all captured as feedback memories and reflected in the /session-summary skill):

  1. Group post tone: neutral, no praise. Removed “thank you all for a strong second session” and similar encouragement language. Group posts should be informational only; motivation comes from the content, not from instructors performing enthusiasm. Patrick was explicit: “We don’t want to be the ones to motivate anyone.” Memory: feedback-group-post-neutral-tone.md.

  2. First-person voice for the posting instructor. When you or Patrick post a session summary, references to you in the body get rewritten to first person (“I mentioned…”), while references to the other instructor stay in third person. Editorial Notes and Group Post sections always stay in third person regardless. Skill Pre-Flight now asks who is posting before drafting. Memory: feedback-session-summary-posting-instructor-voice.md.

  3. Group post lives inside the same .md as the summary. Convention now matches the Winter 2026 layout: a ## Group Post section between the Tags block and the Editorial Notes section. Subject line follows the Winter 1 format: Session N Summary and Assignment N+1. Skill Phase 7e fully documents this with structure, tone rules, and the no-sign-off rule.

  4. Editorial Notes section is now mandatory on every summary. Even if a session has no editorial changes, the section should exist (recording “no editorial changes from initial draft”) so the document shape is consistent across sessions and review history accumulates in one place.

  5. Em dash overuse. Patrick flagged that em dashes were heavy across recent copy. The rule (already in feedback-em-dashes.md) has been strengthened: it’s now treated as a recurring failure mode that needs proactive auditing on every draft, not just review. Mandatory em dash audit added to the skill’s Phase 5 review checklist. The Session 2 summary file body had ~65 em dashes; it now has 6, all in headings (which the rule allows).

Inbox item left for Patrick about adding user_login to the questionnaire export plugin so future session summaries can use BuddyBoss @mentions for participants. Currently the questionnaire export captures full names but not platform handles, so the skill falls back to first names. The detailed implementation plan is in Patrick’s inbox.

No action from you on any of this. This is awareness so the conventions are visible to you the next time you run /session-summary or post a group post. The skill itself enforces the conventions now, but the memories also document the why in case you want to override or refine.

2026-04-12

Section titled “2026-04-12”

[ ] 22:00 ET | Primer Community session — forum reply drafted, tag shortlist reposted, new folder convention

Section titled “[ ] 22:00 ET | Primer Community session — forum reply drafted, tag shortlist reposted, new folder convention”

Added by Claude Code on Patrick’s Mac

What: Patrick and Claude worked through several connected items in the Primer Community forum context tonight. Three things worth your awareness: a drafted reply to Nathalie Dore, a repost of the Forum Tag Shortlist to the Primer Community forum, and a new vault organization pattern for hand-curated Primer Community content.

Forum reply drafted for Nathalie Dore. Nathalie posted a question today on the Primer Community forum about keeping the back foot in high-heel position during Applied Practice Lab — Ascendant Torsion, Lesson 3.5. Patrick dictated the substance of the response and iterated several rounds with Claude on tone, structure, and redundancy reduction. The final version addresses her balance/pelvis question directly, then broadens into how the program is meant to be reapplied across labs and why moderation is central. Patrick will post the reply to BuddyBoss when he next sits down; the draft lives in the sidecar (see below) since the synced topic file will be regenerated by the forum content sync as soon as the reply hits BuddyBoss.

Forum Tag Shortlist reposted to Primer Community. The original Forum Tag Shortlist lived only in the Montreal Winter 2026 cohort forum (topic 21433), which meant practitioners in the Primer Community didn’t have direct access to it. Patrick posted a new Primer Community version tonight at: https://practice.baseworks.com/groups/primer-community/forum/discussion/forum-tag-shortlist-how-to-tag-your-forum-posts/ The new version uses grouped bullet clusters (Forms & Practice Structure, Principles & Patterns, Segments S1–S10, Awareness & Perception, Neuroscience & Physiology, Learning & Adaptation) rather than the flat double-spaced list from the original. 61 tags become much more scannable when grouped by category.

New primer-community/ folder convention in the vault. Previously, anything Primer Community-related lived inside the auto-synced subfolders (topics/, groups/, forums/), which meant hand-curated content had nowhere safe to live — the sync script would regenerate those files on every cycle. A new folder at 02-areas/practice-platform/community-forums-groups/primer-community/ now holds hand-curated material specific to the Primer Community forum: draft posts, reference material, curated follow-ups to specific discussions. The folder has its own index.md and is linked from the parent community-forums-groups.md index. The sync script only touches topics/, forums/, groups/, activity/, and direct-messages/, so content in primer-community/ is safe from regeneration.

Curated-notes sidecar pattern. A related discovery: the forum content sync regenerates the entire topic file body on each cycle (not just frontmatter), so any persistent working notes attached to a specific topic need to live outside topics/. A new sidecar pattern lives at primer-community/260412-keeping-back-foot-in-high-heel-position-notes.md, which holds the recommended tag list, the full draft reply as a persistent backup, and working notes for Nathalie’s topic. This sidecar pattern could become standard for any future topic where you or Patrick draft a substantive response: create a matching sidecar in primer-community/ (or a sibling folder for other groups) so the reply and tag choices survive the sync.

Awareness items (no action needed from you):

  • Sync script gap noted. The forum-content-sync.py script currently doesn’t carry BuddyBoss-level topic tags into the vault frontmatter. Every synced topic ends up with only the static [forum-topic, community, auto-synced] tag set. This is a known gap worth flagging for a future enhancement. For now, the sidecar pattern is our workaround for “recommended tags for this topic” tracking.
  • CSS styling task deferred. Patrick has a pending task to restyle the BuddyBoss forum tag display on practice.baseworks.com to improve visibility. This is a code-level change to the practice platform and will be handled through the baseworks-changelog repo from the VPS in a future session, not from the vault. No vault notes on this — flagging here only so you’re aware it’s on the pending list.

Files touched in the vault this session:

  1. 02-areas/practice-platform/community-forums-groups/topics/260412-keeping-back-foot-in-high-heel-position.md — draft reply added in the Replies section (will be overwritten by sync once Patrick posts on BuddyBoss, which is expected)
  2. 02-areas/practice-platform/community-forums-groups/primer-community/ — new folder created
  3. primer-community/index.md — new index for the folder
  4. primer-community/forum-tag-shortlist-repost.md — clean markdown draft used as the source for Patrick’s BuddyBoss repost
  5. primer-community/260412-keeping-back-foot-in-high-heel-position-notes.md — curated-notes sidecar for Nathalie’s topic (holds tag list and persistent draft reply)
  6. 02-areas/practice-platform/community-forums-groups/community-forums-groups.md — parent index updated to list the new primer-community/ folder

Next steps for Patrick:

  1. Post the drafted reply to Nathalie’s topic on BuddyBoss and apply the recommended tags from the sidecar
  2. Handle the forum-tag CSS restyle via baseworks-changelog repo from the VPS in a future session
  3. Consider whether forum-content-sync.py should be enhanced to pull topic-level tags from the BuddyBoss API — would remove the need for sidecar tag tracking

Next steps for you (Asia): none immediately. This is an awareness note so you know about the new primer-community/ folder and the sidecar pattern next time you’re working on a forum response. If you find the pattern useful (or not), let us know.

2026-04-11

Section titled “2026-04-11”

[ ] 22:45 ET | Session 2 Summary: Ready for review

Section titled “[ ] 22:45 ET | Session 2 Summary: Ready for review”

Added by Claude Code on Patrick’s Mac

What: The English draft of the Session 2 summary is ready for your editorial review at Session 2 Summary.

Program folder: 02-areas/educational-programs/study-groups/2026 (Spring) Study Group Montreal/

Files created/modified:

  1. session-summaries/session-2-summary-en.md — English draft (ready for review)
  2. transcripts/session-2-transcript.md — transcript saved with frontmatter

Source media (NAS): The original transcript, audio, and video files for this session are on the NAS in CEVA stuff/Study Group Spring Media/.

Items for your attention:

  • Speaker attribution check: The transcript attributes a comment about clenching to Natalie, but the speaker labels may be wrong. This is flagged in red in the summary — please verify whether it was Natalie or someone else.
  • Session prep coverage report was generated during this session (not written to file). V-Sit was planned but not practiced; Simple Cross Inflection was reviewed despite being marked as cuttable. If you’d like the coverage notes added to session-prep/session-2-prep.md, let Patrick or Claude know.
  • Translation has not been started — the skill waits for English approval before asking about translation.

What Patrick worked through in this session:

  • Consolidated the Q&A section so it reads as themed teaching points rather than a back-and-forth transcript recap. Natalie and Noémie are named where they asked questions, but the instructor responses are organized by topic (body sensations, session structure/assignments, practice approach).
  • Emphasized the role of assignment completion and spacing in the Q&A discussion — Patrick wanted this point to come through more clearly.
  • Removed participant names from the Common Adjustments section.
  • Established a rule: no “coaching” language for Baseworks — guide, instruct, recommend only.

Next steps after your review:

  1. Confirm or revise the English summary
  2. Decide on translation (French?)
  3. Group post (created separately after both are confirmed)

2026-04-10

Section titled “2026-04-10”

[x] 09:30 ET | Instagram carousel for proprioceptive awareness article — ready for you to polish

Section titled “[x] 09:30 ET | Instagram carousel for proprioceptive awareness article — ready for you to polish”

Added by Claude Code on Patrick’s Mac

What: Patrick and Claude built a 7-slide Instagram carousel (1080x1350, 4:5 portrait) for the proprioceptive awareness campaign. It’s a working draft — content and layout are in place, ready for you to review and refine.

Files in the campaign folder (02-areas/communications/campaigns/2026-04-proprioceptive-awareness-brnet/):

  1. instagram-carousel-preview.html — self-contained preview (open in any browser, no NAS needed). Arrow keys to navigate, “Toggle grid view” to see all slides at once.
  2. instagram-carousel-generate.sh — ImageMagick script that produces all 7 slides. Edit the text, colors, or layout and re-run to regenerate.

The 7 slides:

  1. Title & hook
  2. Blind spot diagram (existing article image)
  3. Three dichotomies
  4. Survey data (47/47/6 split + 48% vocabulary gap)
  5. “The hum” / activation concept
  6. Muscle spindle substrate (existing article illustration)
  7. CTA — experiential prompt + baseworks.com + BRNet mention

Design details: Georgia headings, Jost body text, warm off-white palette (#F5F2EE), circle logo header. Data cards use the article diagram’s purple/blue palette.

To work on it: Open instagram-carousel-generate.sh with Claude, modify what you want, run the script. It outputs to the NAS at /Volumes/baseworks/media/blog-articles/the-mystery-of-proprioceptive-awareness/carousel-instagram/. The script auto-downloads the Jost font if needed.

When finalized: The final carousel images must be saved to the NAS in that same folder (/Volumes/baseworks/media/blog-articles/the-mystery-of-proprioceptive-awareness/carousel-instagram/) before uploading to schedule the post. The campaign folder in Obsidian holds only the working files — final production images live on the NAS under Media/Baseworks.

Caption and hashtags are already drafted in the campaign doc under the “Instagram — Baseworks Account” section.

2026-04-08

Section titled “2026-04-08”

[ ] 22:15 ET | Forum content sync — major fixes + new features (DMs, translations, thread summaries)

Section titled “[ ] 22:15 ET | Forum content sync — major fixes + new features (DMs, translations, thread summaries)”

Added by Claude Code on Patrick’s Mac

The forum content ingestion system (System 3, deployed yesterday) had a significant gap: the BuddyBoss REST API doesn’t return group feed posts for private groups. Only 7 of 49 activity posts were being captured. This has been fixed, along with several new features.

What changed:

  1. Activity sync fixed — switched from REST API to direct SQL queries. Now captures all 49 group feed posts + 41 activity comments (previously missing entirely). Activity comments appear inline under their parent post.

  2. Admin DMs now synced — all DM threads involving you or Patrick are pulled into the vault at community-forums-groups/direct-messages/. 42 threads captured. Broadcast messages to cohorts are included. Participant-to-participant private messages are NOT captured.

  3. Automatic English translations — non-English messages (French, Japanese) now show the original text first, followed by an English translation in a blockquote. Runs automatically after each sync.

  4. Thread summaries — settled threads (48h inactive, 1+ comments) get AI-generated structured metadata: topic, category, participants, resolution status, and semantic tags. Runs daily at 1 AM ET.

  5. Permalinks — each activity post now links directly to practice.baseworks.com/news-feed/p/{id}/ instead of showing a raw HTML comment.

  6. Sync frequency — increased from every 2 hours to every 15 minutes.

Vault locations:

  • Activity digests: community-forums-groups/activity/
  • DM threads: community-forums-groups/direct-messages/
  • Full plan: Forum Content Ingestion Plan

Action needed: Review at your convenience. The DMs contain personal participant communications — worth being aware they’re now in the vault (which is private/internal). If you’d like any threads excluded or the admin user filter adjusted, let Patrick know.

[x] 21:45 ET | CSS icon backslash issue — RESOLVED same session

Section titled “[x] 21:45 ET | CSS icon backslash issue — RESOLVED same session”

Added by Claude Code on Patrick’s Mac

Resolved: Payment Methods icon rule moved from Customizer CSS to child theme assets/css/custom.css. Backslashes are now permanently safe from wp_kses sanitization. No action needed.

[ ] 10:15 ET | Campaign plan: Proprioceptive Awareness article + BRNet — your input needed

Section titled “[ ] 10:15 ET | Campaign plan: Proprioceptive Awareness article + BRNet — your input needed”

Added by Claude Code on Patrick’s Mac

Campaign plan for promoting the updated “Mystery of Proprioceptive Awareness” article, timed to precede the BRNet 2026 acceptance announcement on LinkedIn. Full plan, deliverables, sequencing, and 5 open questions are in the campaign note:

2026-04-proprioceptive-awareness-brnet

See the Open Questions section at the bottom — update decisions directly in the campaign note, then add a note to Patrick’s inbox so he knows to continue.

2026-04-07

Section titled “2026-04-07”

[ ] 22:51 ET | Vault health audit — 149 broken wikilinks + 244 backtick path warnings — cleanup needed

Section titled “[ ] 22:51 ET | Vault health audit — 149 broken wikilinks + 244 backtick path warnings — cleanup needed”

Added by Claude Code on Patrick’s Mac

The new daily vault audit (now reporting to #agent-alerts in Slack every morning at 4:15 AM) surfaced pre-existing broken wikilinks. None are caused by recent work — they’ve accumulated over time. Total: 149 broken wikilinks + 244 backtick path warnings out of 2,492 total links checked.

Section titled “Broken wikilinks (149 total)”

Top missing targets — these account for most of the breakage:

Missing targetCountLikely cause
Micro-Movements15File renamed or never created — referenced across multiple vault captures and forum content
montreal-film-schools-master-list13All in 02-areas/collaborations/photography-videography-2026/contacts/ — planned file never created
Sense Control Adapt11Baseworks concept — file may have been renamed or needs to be created
groups/9Partial path references that don’t resolve
_index8Old-style index references from before the rename to index.md
posting-job-board5Planned file in photography contacts, never created
study-group-participant-interview-request4Reference to a planned document
wikilinks / wikilink / wiki-links6Example/placeholder text in documentation files (KB-Site logs, etc.) — not real broken links

Other categories:

  • settings-local-json-backup-patrick-mac-mini-2026-04-07 (3) — the JSON backup file exists but isn’t an .md file, so Obsidian can’t resolve it as a wikilink. Harmless.
  • image.png, filename, Page (6) — example placeholders in documentation, not real links
  • Various one-off references to files that were moved or renamed during today’s reorganization

Files with the most broken links: contacts-directory.md (photography contacts), additional-resources.md, various campaign files, event-post-system.md, _session-summary-guidelines.md, _campaign-creation-guidelines.md

Backtick path warnings (244 total)

Section titled “Backtick path warnings (244 total)”

These are paths written as `02-areas/path/to/file.md` instead of [wikilinks](/wikilinks/). Many are in CLAUDE.md, setup guides, voice guides, and technical documentation where backtick paths are appropriate (filesystem references for Claude Code, not navigational links for Obsidian). The audit script flags them but most are intentional per the vault’s own wikilink standards (CLAUDE.md says backtick paths are fine in technical docs).

Section titled “Recommended approach”
  1. Create Micro-Movements.md and Sense Control Adapt.md as Baseworks concept files (or redirect to existing files if they were renamed) — you’d know best whether these should be standalone concept files or aliases to existing content
  2. Create montreal-film-schools-master-list.md or remove the dead links from the photography contacts directory
  3. Fix the _index → index references (8 leftover from the earlier index file rename plan)
  4. Ignore placeholder links in documentation files (wikilinks, image.png, filename, Page) — these are examples in KB-Site logs and implementation docs
  5. Run python3 scripts/check-wikilinks.py after fixes to verify the count drops

To check the full list at any time: python3 scripts/check-wikilinks.py To check only recently changed files: python3 scripts/check-wikilinks.py --changed

[ ] 22:26 ET | Claude Code settings cleanup — please run on your machines

Section titled “[ ] 22:26 ET | Claude Code settings cleanup — please run on your machines”

Added by Claude Code on Patrick’s Mac

Patrick’s .claude/settings.local.json on his Mac Mini was cleaned up — 52 accumulated permission entries reduced to 21. Most removed entries were one-time session artifacts, redundant patterns, and WebFetch domains for tools we researched but never adopted.

Action needed: When you have a moment, run the same cleanup on your MacBook and Mac Mini. Start a session in the vault and ask Claude Code to review .claude/settings.local.json and streamline it using the same approach documented here:

Patrick’s MacBook Pro also needs the same cleanup (it wasn’t open during this session).

The VPS doesn’t have a settings.local.json (it uses dangerousMode), so no cleanup needed there.

This is low priority — all machines work fine as-is. The cleanup just removes clutter from old sessions.

[ ] 21:35 ET | Resources reorganized + upcoming consolidation audit — your input welcome

Section titled “[ ] 21:35 ET | Resources reorganized + upcoming consolidation audit — your input welcome”

Added by Claude Code on Patrick’s Mac

Two things here: a completed reorganization, and an upcoming piece of work where your input would be valuable.

1. 03-resources/ is now organized

Section titled “1. 03-resources/ is now organized”

The 14 loose files that were sitting directly in 03-resources/ have been sorted into topical subfolders:

  • vault-and-tooling/ — media storage plan, media organization memo, Google Workspace CLI setup, sitemap reference
  • translation/ — all three WPML plans + Japanese translation conventions
  • community/ — forum moderation plan (still awaiting your review from the earlier inbox item)
  • research/ — Karpathy LLM wiki pattern evaluation
  • executed-plans/ — completed plans preserved for reference (vault SQLite sync, forum ingestion, index rename fix, permission pattern fix)

Each subfolder has an index file (00-{folder}-index.md) that sorts to the top and shows a descriptive name in Obsidian’s graph view. All wikilinks, skill file paths, and script paths have been updated. Nothing should be broken.

2. Upcoming: instruction consolidation audit — your input welcome

Section titled “2. Upcoming: instruction consolidation audit — your input welcome”

During the reorganization, Patrick and Claude identified that instructions, operational references, and folder indexes overlap across multiple locations in the vault. Examples:

  • Voice guide loading instructions appear in both CLAUDE.md files AND voice-guides/README.md
  • Server/infrastructure details appear in both agent-system/README.md AND 00-inbox/claude-code-shared-context.md
  • The claude-code-skills/index.md in Obsidian may be redundant with the actual .claude/skills/ folder
  • Some README files are instruction guides (not indexes) and might belong as skills or in CLAUDE.md instead
  • 19 index.md files across 02-areas/ have generic names that are ambiguous in graph view and fragile for wikilink resolution

The next session will audit all of this and propose a consolidation plan. Before that happens, if you have thoughts on any of the following, add them here or flag in Slack:

  1. Do you reference the voice-guides/README.md directly, or do you just load the guides via CLAUDE.md?
  2. Do you ever open the claude-code-skills/index.md in Obsidian to find skills, or do you use / commands?
  3. Any folders where you find the naming confusing or hard to navigate?

No urgency — this is informational. Patrick has the same item in his inbox.

2026-04-06

Section titled “2026-04-06”

[ ] 17:00 ET | Google Workspace CLI setup — persistent auth ready for you

Section titled “[ ] 17:00 ET | Google Workspace CLI setup — persistent auth ready for you”

Added by Claude Code on Patrick’s Mac

Patrick set up the Google Workspace CLI (gws) with persistent authentication for the baseworks.com domain. The RAPT (re-authentication) policy has been changed to “never expire,” which means once you log in, you stay logged in indefinitely. No more repeated browser auth flows.

What you need to do

Section titled “What you need to do”

1. Install gws (if not already installed):

brew install gws

2. Authenticate once:

gws auth login

This will open a browser window. Log in with asia@baseworks.com and grant the requested permissions. After that, you should never need to do this again.

3. Test it:

gws gmail users messages list --params '{"userId": "me", "maxResults": 1}'

If you get a JSON response with a message ID, you’re good.

What this gives you

Section titled “What this gives you”
  • gws gmail — read, send, draft emails
  • gws drive — list, read, manage files and shared folders
  • gws calendar — manage calendars and events
  • gws docs — read and write Google Docs
  • gws sheets — read and write spreadsheets
  • gws slides — read and write presentations
  • gws tasks — manage task lists

Claude Code can use all of these via the gws command. This replaces the need for the Google Workspace MCP connection.

Security notes

Section titled “Security notes”
  • Credentials are stored encrypted in your macOS Keychain (not as a file on disk)
  • Protected by FileVault and your login password
  • The “never expire” RAPT setting was applied domain-wide by Patrick in the Google Admin Console — it applies to both accounts automatically
  • If you ever need to revoke access: gws auth logout

If you have issues

Section titled “If you have issues”

If you get an invalid_grant error, just run gws auth login again. With the new RAPT setting, this should be a one-time event rather than a recurring annoyance.

[ ] 11:00 ET | Content repurposing and memes — your input needed

Section titled “[ ] 11:00 ET | Content repurposing and memes — your input needed”

Added by Claude Code on Patrick’s Mac

Patrick is working on building out campaign archives and content strategy. During this session we documented the January 16, 2026 newsletter (your “What Movement Training Misses” article) as a full campaign in the vault, and started a framework for a new blog post by Patrick expanding the Brain Fodder on learning styles.

This led to a broader conversation about content repurposing across social media — specifically the idea of creating reusable “meme” units from our published content. Patrick wants your input before we develop this further.

The meme concept

Section titled “The meme concept”

Not traditional internet memes. These would be reusable conceptual units — a single idea, stat, or contrast extracted from blog posts and newsletters that can be rendered across formats:

  • Quote cards / carousel slides for Instagram
  • Short caption posts for Facebook
  • Pull-quotes for newsletters
  • Standalone social media posts that can rotate through feeds over time

Examples from your article alone

Section titled “Examples from your article alone”

Your “What Movement Training Misses” article contains several natural meme units:

  • “97-99% of movement instruction focuses on what you can see” — the core stat that frames the gap
  • “66% still experience chronic tension despite 5+ modalities” — the participant data point
  • “You can’t watch your way through distributed activation” — the simultaneity argument
  • The Baseworks vs. yoga vs. Feldenkrais comparison (60% vs. 1-3% vs. 27%) — could work as a simple chart or infographic card

Why this matters

Section titled “Why this matters”

Social media feeds are ephemeral — content disappears within hours. Repurposing lets us re-enter the same ideas from different angles over time without repeating ourselves. The strategy aligns with our niche-building approach: informational, substantive content that the right people recognize and engage with. Not promotional, not sensational — just the ideas themselves, presented clearly.

What we need from you

Section titled “What we need from you”
  • Quality control: These units would draw from your scientific framing and data. You should have a say in which claims are suitable for standalone presentation (out of full article context) and which need their surrounding context to be accurate.
  • Tone check: Making sure compressed versions of your arguments don’t lose precision or drift into oversimplification.
  • Ideas: Are there other reusable units from your existing or planned writing that you think would work well in this format?

Patrick said he’d like to discuss this with you before we build anything. No action needed now — just flagging for when you have time to think about it.

Section titled “Related vault files”

2026-04-01

Section titled “2026-04-01”

[ ] 22:55 ET | Questionnaire system deployed to practice platform — Phase 2 plan

Section titled “[ ] 22:55 ET | Questionnaire system deployed to practice platform — Phase 2 plan”

Added by Claude Code on Patrick’s Mac

Patrick and Claude deployed the Event Participation Questionnaire system to practice.baseworks.com tonight. Summary of what’s live:

  • Background profile tab — new “Background” tab on BuddyBoss profiles with the questionnaire form (same form as on baseworks.com). URL: /members/me/background/
  • Persistent prompt banner — bottom-right notification card for enrolled participants who haven’t completed the form. Tag-based (Study Group + Practice Sessions tags). X hides for current page; “Later” dismisses for 24 hours.
  • Dashboard teaser — [bw_dashboard_teaser] shortcode shows muted preview of Primer + Activity dashboard for practice-session-only users with CTA linking to baseworks.com/programs/
  • Obsidian export — WP-CLI command on baseworks.com exports Form 40 entries to event-participant markdown files in the vault. Running 6x daily via cron on agents VPS.
  • Staging restored — pracstage.baseworks.com pushed from production, post-push cleanup done, fonts fixed.

Phase 2 items (not yet started):

Section titled “Phase 2 items (not yet started):”
  1. Groups teaser page — muted group cards for practice-session-only users (Elementor page + shortcode + tag-based menu visibility)
  2. Soft-gate form completion — require questionnaire before certain course/community milestones
  3. Real-time Obsidian sync via webhook (replace cron)
  4. Custom multi-step form replacing Formidable
  5. Broader data accumulation from forum/DM/email

Files (in baseworks-changelog repo):

Section titled “Files (in baseworks-changelog repo):”
  • sites/practice.baseworks.com/mu-plugins/bw-profile-background-tab.php
  • sites/practice.baseworks.com/mu-plugins/bw-questionnaire-prompt.php
  • sites/practice.baseworks.com/mu-plugins/bw-dashboard-teaser.php
  • sites/baseworks.com/mu-plugins/bw-questionnaire-export-cli.php

No action needed from you right now — this is informational so you have full context.

[ ] 15:00 ET | Google Calendar setup — Baseworks MTL Sessions + participant-facing calendars

Section titled “[ ] 15:00 ET | Google Calendar setup — Baseworks MTL Sessions + participant-facing calendars”

Added by Claude Code on Patrick’s Mac

Patrick set up Google Calendar integration for all Spring/Summer 2026 studio sessions. Three calendars now exist under pat@baseworks.com:

1. Baseworks MTL Sessions (private — you and Patrick)

  • Combined calendar with all Study Group + Practice Session events
  • Shared with your Workspace email
  • Color-coded: teal for Study Group, green for Practice Sessions
  • Subscribe via iCal URL from the calendar’s Integrate settings (Settings → Integrate calendar → Secret address in iCal format)

2. Baseworks Study Group — Spring 2026 (public — for participants)

  • 7 sessions, April 4 – May 16
  • Set to public so participants can subscribe without seeing pat@baseworks.com

3. Baseworks Practice Sessions — Spring/Summer 2026 (public — for participants)

  • 13 sessions, April 4 – June 27
  • Same public setup

All events include:

  • Session/week number + studio number (Studio 1 or Studio 2) in the title
  • Full address: Proto Studio, 5333 Av. Casgrain, suite 1107, Montréal, QC H2T 1X3
  • Google Maps directions link in the notes (workaround for Apple Calendar not making the location field clickable)

Action needed:

  1. Confirm the private calendar (Baseworks MTL Sessions) is visible in your Google Calendar — Patrick shared it with you
  2. Grab the public iCal URLs for the two participant-facing calendars (Settings → Integrate calendar → Public address in iCal format) — these need to be added to the Practice Platform as “Add to Calendar” links for participants
  3. Note on Apple Calendar: The location field is not clickable when synced from Google Calendar to iCal — this is an Apple limitation. The Google Maps link in the notes is the workaround.

2026-03-27

Section titled “2026-03-27”

[ ] 22:30 ET | Media CDN pipeline live — WPRUS test needed + new media workflow

Section titled “[ ] 22:30 ET | Media CDN pipeline live — WPRUS test needed + new media workflow”

Added by Claude Code on Patrick’s Mac

The Baseworks media CDN is now operational at media.baseworks.com. All images are served from Backblaze B2 via Cloudflare CDN. The Obsidian vault will no longer store binary image files — instead, markdown files reference images via CDN URLs (e.g., ![alt text](https://media.baseworks.com/path/to/image.webp)).

Action needed:

  1. Test WPRUS cross-site login sync with swantest2 (swanonthecliff@gmail.com) — Cloudflare proxy was re-enabled for baseworks.com, practice.baseworks.com, and crm.baseworks.com. The /etc/hosts entries on the server are still in place, so WPRUS should still work. Please confirm sync works as expected.
  2. Review the media organization memo at media-organization-memo — this outlines how photos will be organized going forward (storage vs. discovery, naming conventions, manifest system). Your input on the forms reference library and taxonomy is especially valuable since you work closely with the photo assets.

What changed:

  • /compress-photos skill now handles the full pipeline: resize originals → create WebP + JPEG → upload to B2 → output CDN URLs
  • All existing vault images (102 files) are now on the CDN
  • Markdown files reference CDN URLs; images render inline in Obsidian as before
  • NAS (/volume1/baseworks/media/) is the local workspace for browsing and sorting photos before upload

No action needed on:

  • The CDN setup itself — it’s working
  • Existing campaign files — already updated

2026-03-25

Section titled “2026-03-25”

[ ] 23:45 ET | Synology SSH — your keys are authorized, ready to test

Section titled “[ ] 23:45 ET | Synology SSH — your keys are authorized, ready to test”

Added by Claude Code on Patrick’s Mac

Both your SSH public keys have been added to the Synology NAS. ssh synology should now work from both your Mac Mini and your MacBook Air without a password.

Action: Test from each machine:

ssh synology "echo connected"

If either fails, let us know which machine and the error message.

Update (2026/03/25): both failed, Patrick notified.

[ ] 23:15 ET | Winter Study Group Campaign — Final Revision Complete, Ready for Your Review

Section titled “[ ] 23:15 ET | Winter Study Group Campaign — Final Revision Complete, Ready for Your Review”

Added by Claude Code on Patrick’s Mac

The Winter Study Group campaign has been fully revised. All campaign content (social posts, newsletter feature, LinkedIn article) has been updated to match the current blog post (8th draft, 2026-03-25), the latest voice guide (v2.0–2.2), and Patrick’s content strategy direction. The ball is in your court.

What changed in this revision pass

Section titled “What changed in this revision pass”

Factual corrections (matching current blog post):

  • “massage therapist” → “movement educator with a yoga teaching background” across Facebook, Instagram, and vignettes table
  • LinkedIn article cut point quote updated (“the in-person sessions” not “in-person classes”)
  • “Six weeks” → “Seven weeks” in Facebook and Instagram
  • All “practised/practising” → “practiced/practicing” (American English per voice guide v2.1)
  • Blog draft count updated to 8th draft
  • Alt text spelling corrected

Blog post:

  • H2 subtitle/deck added below the H1 for AI discoverability: “What the Winter 2026 cohort in Montreal looked like, what participants reported, and what we observed.”
  • No other changes to the blog post

Tone and strategy revision (Patrick’s direction):

  • Newsletter lead-in, LinkedIn feed post, and Facebook opening all rewritten to mirror the blog’s documentary register — contextual framing about the Tokyo studio history and the developmental question (can the method be made learnable without that daily studio backdrop?), not promotional hooks
  • LinkedIn feed post now frames why the article matters, not just what it covers
  • Facebook and Instagram marked as collaboration posts between Patrick’s personal account and the Baseworks account, with first-person attribution in the closing (“I wrote about…”)

LinkedIn publishing structure:

  • Article to be published from Patrick’s personal account (not Baseworks company page) for better reach
  • Byline: “Patrick Oancia and Ksenia Shcherbakova” in the article body
  • Canonical URL set to baseworks.com article so search engines credit the original
  • Baseworks company page reshares

Campaign guidelines updated:

  • New “Content strategy: niche-building, not mass appeal” section added to _campaign-creation-guidelines.md
  • Publishing sequence updated with LinkedIn canonical URL, collaboration post format, and personal account publishing as standard practices
  • Platform tone table updated

What needs your review

Section titled “What needs your review”

  1. Full campaign copy review — Read through all social posts (LinkedIn article + feed post, Facebook, Instagram) and the newsletter feature section. Confirm the tone, voice, and factual accuracy. Files:

    • Campaign note: 02-areas/communications/campaigns/2026-03-winter-study-group-campaign/2026-03-winter-study-group-campaign.md
    • Newsletter: 02-areas/communications/newsletters/2026-03-newsletter/2026-03-newsletter.md
    • Campaign guidelines: 02-areas/communications/campaigns/_campaign-creation-guidelines.md

  2. Create Brain Fodder image variations — The Brain Fodder section (“What are you not noticing?”) needs image assets for the newsletter and social platforms. Place them in: 02-areas/communications/campaigns/2026-03-winter-study-group-campaign/2026-03-winter-study-group-recap-assets/

  3. Practice Platform links decision — The newsletter (Section 4 and footer) links directly to practice.baseworks.com. Per the linking rule, public traffic shouldn’t go there since the app is gated. Should these link to baseworks.com instead, or is it acceptable in a newsletter context? Flag for Patrick if unsure.

[ ] R&D documentation — separate method development from program development

Section titled “[ ] R&D documentation — separate method development from program development”

Added by Claude Code on Asia’s Mac Mini

Context: While reviewing the Winter Study Group blog post, Asia noted that the standard R&D sequence description conflates two distinct conceptual tracks that should be documented separately.

The conflation: The sequence (digitize syllabus → build Practice Platform → develop Primer → design hybrid format → first Study Group) is correct chronologically, but mixes:

  1. R&D of the Baseworks Method itself — the movement pedagogy, principles, taxonomy, forms vocabulary (the what)
  2. R&D of the programming/delivery format — Study Groups, Study Labs, hybrid format, Practice Platform as a delivery vehicle (the how we teach it)

What to do: Develop a documentation note (or expand an existing one in 02-areas/method-admin/core/) that clearly separates these two tracks. The goal is that any future description of the R&D phase can point to this distinction — so blog posts, the About page, and program pages don’t accidentally collapse the two.

Coordinate with Patrick on the right location and scope before writing.

[ ] Synology SSH — test ssh synology on both machines after Patrick authorizes keys

Section titled “[ ] Synology SSH — test ssh synology on both machines after Patrick authorizes keys”

Added by Claude Code on Asia’s MacBook Air

Patrick’s inbox (2026-03-25) has both public keys and instructions to add them in Synology DSM. Once he confirms:

  • Mac Mini: run ssh synology in terminal — should connect without a password prompt
  • MacBook Air: run ssh synology in terminal — should connect without a password prompt

Both machines have Tailscale connected and the ssh synology alias configured.

2026-03-20

Section titled “2026-03-20”

[x] 09:15 ET | Any Guay CE certificate inquiry — new reply received, needs discussion before responding

Section titled “[x] 09:15 ET | Any Guay CE certificate inquiry — new reply received, needs discussion before responding”

Added by Claude Code on Patrick’s Mac

Any replied to Patrick’s email about CE documentation. She’s gracefully accepting our position but also pushing back on the logic. Patrick wants to discuss this with you before responding.

Her reply (summary):

  • Thanks Patrick for the detailed explanation
  • Says she didn’t choose the program just to check a box — she was genuinely interested
  • Would love to do a multi-day “Baseworks retreat” someday
  • Pushes back with an analogy: “It’s like if I gave you a massage and you used the receipt to submit to your insurance. But if the therapist writes on the receipt ‘we don’t want this recognized for reimbursement’… that’s a bit bizarre, no?”
  • Says she never imagined she’d need to ask “will I have the right to a detailed receipt?” — it seemed obvious
  • Notes it’s to our credit that we want to choose our clientele, but “just because someone has to do CE by obligation doesn’t mean they do it without good intentions”
  • Signs off saying she’ll accept whatever we offer

The core question Patrick is sitting with:

Does her analogy actually hold, or is she missing a key distinction?

Claude’s analysis of the discrepancy:

The massage receipt analogy breaks down in an important way:

  1. A massage therapist issues receipts as standard practice. The receipt exists because a transaction occurred — it documents a commercial exchange. What the client does with it afterward (insurance, taxes, nothing) is secondary. The receipt’s primary purpose is to document what happened.

  2. We don’t issue completion documentation as standard practice. She’s not asking for a receipt that already exists — she’s asking us to create a new document whose sole purpose is to be submitted to her professional association as evidence of CE hours.

  3. The massage receipt says: “This happened.” What she’s asking for says: “This counts.” Those are different things.

The analogy would only work if the massage therapist didn’t normally give receipts and the client said, “Can you write something up that I can submit to my insurance?” At that point, the therapist isn’t just documenting what happened — they’re producing something specifically to interface with a reimbursement system. And it would be reasonable for the therapist to say, “I don’t produce documentation for insurance purposes.”

What she’s overlooking:

Patrick’s previous email explained why we don’t want to enter the CE ecosystem — not just that we don’t, but the reasoning (attracting box-checkers, repositioning Baseworks within a credentialing framework, etc.). She doesn’t engage with any of that. Instead, she pivots to the receipt analogy, which reframes the issue as “you’re being weird about a piece of paper” — stripping away the reasoning Patrick gave.

Where she has a point:

The awkwardness of offering a letter with a disclaimer. When Patrick said “we could give you a personal letter but note that we’re not a CE provider,” he was trying to accommodate her while maintaining the position. She’s correctly pointing out that this middle ground is strange — issuing a document but asking her not to use it for its obvious purpose.

But the answer to that awkwardness isn’t “drop the disclaimer.” The answer might be that offering the letter at all was the accommodation going too far.

Options to discuss:

  1. Hold the line: We don’t produce documentation for CE purposes. If she wants to tell her association what she did, she can describe it herself — she has all the information. We’re just not going to author that representation.

  2. Issue a plain letter without disclaimer: Just confirm participation and hours, let her do what she wants. (But this sidesteps the real issue — she’s asking us to produce something specifically for CE submission.)

  3. Something in between: Clarify the discrepancy in her analogy without being harsh, acknowledge the awkwardness of the middle-ground offer, and land somewhere.

Full text of her reply: See Any Guay — Continuing Education Certificate Inquiry (Patrick will add her latest message there after your discussion).

Requested action: Discuss with Patrick before any response is sent. No deadline pressure — her association deadline is April 1, but we’re not obligated to rush.

2026-03-18

Section titled “2026-03-18”

[ ] 16:15 ET | New campaign infrastructure + /create-campaign skill — setup instructions for your machines

Section titled “[ ] 16:15 ET | New campaign infrastructure + /create-campaign skill — setup instructions for your machines”

Added by Claude Code on Patrick’s Mac

What happened: Patrick built a campaign/newsletter content infrastructure in the vault today. There is now a structured workflow for creating content campaigns (blog + newsletter + social media) that are fully wikilinked into the knowledge base. A Claude Code skill (/create-campaign) automates the process.

What’s already done (no action needed from you):

  • Campaign and newsletter directory structure under 02-areas/communications/
  • First campaign note (Winter Study Group Recap) and first newsletter issue (March 2026) created
  • Campaign creation guidelines: _campaign-creation-guidelines
  • Campaign index (editorial calendar): _campaign-index
  • The skill file is checked into the vault repo at .claude/skills/create-campaign/SKILL.md — it arrives on all machines via git pull

VPS: Already set up. The skill file was pulled to /srv/baseworks/knowledge-base/ and both patrick and asia users have access. When you SSH into the VPS and start Claude Code in the vault directory, /create-campaign will be available.

What you need to do on your Macs (~5 min per machine):

Do this on Mac Mini, M1 Laptop, and MacBook Air:

  1. Pull the latest vault changes:

    Terminal window
    cd ~/Obsidian/baseworks-kb-shared-brain
    git pull

    This brings in the .claude/skills/create-campaign/SKILL.md file and all the new campaign structure.

  2. Verify the skill is visible:

    • Open the vault folder in VS Code
    • Start or open Claude Code in the sidebar
    • Type / — you should see create-campaign in the autocomplete list
    • If it doesn’t appear, reload the VS Code window: Cmd+Shift+P → “Developer: Reload Window”, then try again

  3. Test it (optional):

    • Type /create-campaign Test — Claude will start the campaign creation workflow
    • You can cancel after confirming it loads — this is just to verify it works
    • The skill will walk you through: KB research → planning → file creation → index updates → wikilink validation

How to use it going forward:

  • When you or Patrick want to create a new campaign: /create-campaign [topic]
  • Example: /create-campaign Spring 2026 Study Group Enrollment
  • Claude will research the KB, propose a plan, and walk through the full creation process
  • The guidelines document has the full reference: _campaign-creation-guidelines

How skills work in Claude Code:

  • Skills are .md files in .claude/skills/skill-name/SKILL.md inside the project
  • They show up in the / menu when you start typing
  • They’re checked into git, so they sync across all machines automatically on git pull
  • You can create new skills for any repeatable workflow — just create a new folder under .claude/skills/ with a SKILL.md file

Browsing skills inside Obsidian:

  • The .claude/ folder is invisible to Obsidian (it’s a dotfolder)
  • All skills are indexed at Claude Code Skills — this is the Obsidian-visible reference
  • Each skill has a guidelines document somewhere in the vault (linked from the index) — the human-readable version of what the skill does
  • When you create a new skill, add it to both .claude/skills/ (for Claude Code) and the skills index (for Obsidian visibility)

Requested action: Run git pull and verify the skill appears on at least one of your machines. No rush.

[ ] 15:30 ET | Research needed — Google Drive media linking in Obsidian campaign notes

Section titled “[ ] 15:30 ET | Research needed — Google Drive media linking in Obsidian campaign notes”

Added by Claude Code on Patrick’s Mac

Context: Patrick is building a campaign/newsletter infrastructure in the vault under 02-areas/communications/. Campaign notes will reference images via standard markdown image links rather than storing binary files in the git repo. The preferred workflow: find images in Google Drive (via Gemini or the anti-gravity agent manager), then drag or paste the reference into the campaign note in Obsidian so images render inline.

The question: When you drag or paste a Google Drive image reference into an Obsidian note, does it arrive as a renderable image URL or as a sharing page link? Google Drive sharing links (https://drive.google.com/file/d/ID/view) won’t render inline in Obsidian — only direct image URLs do (https://drive.google.com/uc?export=view&id=FILE_ID).

What to test (either machine):

  1. Find an image in Google Drive
  2. Try dragging it / copy-pasting the link into an Obsidian note
  3. Check: does the image render inline, or do you just see a link?
  4. If it doesn’t render, try rewriting the URL as https://drive.google.com/uc?export=view&id=FILE_ID and see if that works

Why this matters: The new campaign structure stores all image references directly in campaign notes (no separate manifest files). If Drive URLs need conversion, we’ll need to either automate that or use an alternative host (the VPS FileBrowser at files.baseworks.com would give direct URLs natively).

Requested action: Test when you have 5 minutes and report findings. No rush — this is a workflow question for the campaign infrastructure, not blocking anything immediately.

2026-03-07

Section titled “2026-03-07”

[ ] 12:30 ET | Quebec language compliance — French checkout flow and terms pages needed

Section titled “[ ] 12:30 ET | Quebec language compliance — French checkout flow and terms pages needed”

Added by Claude Code on Patrick’s Mac

Context: Patrick completed a Quebec language compliance review (Bill 96 / Bill 101). The course content is exempt (adult education), but the commercial materials — terms, privacy policy, enrollment flow — need French versions. This is Phase 1 of a phased plan.

Full compliance roadmap: Quebec Language Compliance — Bill 96

What needs to be implemented (Phase 1):

1. French terms checkbox on all Montreal checkout entry points:

The goal: before any add-to-cart redirect, users see a bilingual checkbox with a link to the French terms. The CTA button stays hidden/disabled until the checkbox is checked.

Checkbox text:

J’ai lu et j’accepte les conditions générales / I have read and accept the Terms and Conditions

Three places this needs to go:

Entry pointWhere in codeWhat to modify
Practice Sessions intake form — Outcome A cardbaseworks-changelog/sites/baseworks.com/code-snippets/2026-03-05-practice-sessions-quiz-v2.phpAdd checkbox + terms link before the “Purchase Intro Session Pass” CTA in the outcome HTML. Hide CTA until checked.
Practice Sessions booking widget — alumni/standardbaseworks-practice-sessions.php mu-plugin on baseworks.comAdd same checkbox before the checkout button in the widget output
Study Group — “Join the Program” buttonElementor page for study group eventAdd checkbox above the CTA (either Elementor edit or shortcode wrapper)

Technical reference: Practice Sessions Infrastructure — Known Gaps

2. French practice sessions page with French intake form:

  • Duplicate the practice sessions page as a standalone French WordPress page (not WPML)
  • Duplicate the [bw_practice_quiz] shortcode with French strings — either [bw_practice_quiz_fr] or a lang="fr" parameter
  • The French Outcome A card should include the checkbox natively with French terms linked
  • Cross-link between English and French pages

3. French policy pages (Patrick will handle the translation, you handle the WordPress pages):

  • 5 standalone WordPress pages with translated policy content (not Termageddon widgets, not WPML)
  • Patrick will provide the translated text; you create the pages and add cross-links between English and French versions

Not needed for Phase 1:

  • No WPML French language addition
  • No WooCommerce cart translation
  • No custom WooCommerce plugin
  • Professional translation review comes in Phase 2

Requested action: Review this plan and flag any implementation concerns. No rush to start — Patrick is still working through the compliance roadmap and will coordinate timing.

Completed

Section titled “Completed”
2026-04-07
  • 2026-04-07 22:00 ET — Forum content sync + moderation plan review complete. Asia’s responses to all five questions sent to Patrick’s inbox. Key decisions: disable auto-notifications pending moderation approval, hide flagged posts rather than delete, use support@baseworks.com for removal emails, keep moderated posts in vault and adjust policy case by case.
2026-03-27
  • 2026-03-03 14:30 ET — Voice guide review complete. Guide confirmed by Asia, updated to v1.0 active. Added: essay/article voice section, pronouns/collective claims section, capacity framing and condescension risk section. Draft warning and “what to flag” sections removed. Voice Guide — Asia / Ksenia
2026-03-26
  • 2026-03-26 00:30 ET — Winter Study Group Photos — Renamed and uploaded to vault campaign assets folder. 20 WebP files + JPEG originals pushed to git. Patrick to review names and upload to WordPress.
2026-03-25
  • 2026-03-21 09:55 ET — Tailscale setup on MacBook Air complete (Antigravity inbox items archived). Installed app, signed in with Google, CLI added to PATH, connected to Tailscale network. ssh synology alias configured using existing id_ed25519_server key. Key authorization request sent to Patrick. Pending: test ssh synology once Patrick authorizes.
2026-03-24
  • 2026-03-10 16:45 ET — Practice Sessions event widget redirect confirmed working (Fluent Snippet 41). Acknowledged.
  • 2026-03-10 22:15 ET — Multilingual translation plans reviewed. Awareness only; no action needed.
  • 2026-03-16 09:30 ET — Contact inquiries tracking system reviewed. No action required.
  • 2026-03-04 12:10 ET — Google Drive on VPS reviewed. Awareness only.
  • 2026-03-04 10:15 ET — FileBrowser setup + screenshot sharing reviewed. No action required.
  • 2026-03-13 14:30 ET — Winter Study Group recap campaign reviewed. Awareness only; review request coming once drafts are ready.
  • 2026-03-17 13:00 ET — Facebook French ad (Brigitte Bouthillier follow-up). Patrick had already responded; no further action needed.
  • 2026-03-24 15:30 ET — Voice guide updates (em dash, capitalization) reviewed. Em dash confirmed. Capitalization confirmed with clarification on ‘Baseworks Practice’ lowercase rule; pending Patrick review of addition.
  • 2026-03-14 18:00 ET — Clementine media consent inquiry reviewed. Vault documentation confirmed accurate.
  • 2026-03-19 15:00 ET — Winter Study Group blog post reviewed. Feedback delivered via _feedback-winter-study-group-asia.md; Patrick is working on revisions.
  • 2026-03-10 16:30 ET — Study Group page Online section edits confirmed implemented on live Elementor pages.
  • 2026-03-10 12:30 ET — Participation terms interpreter clause reviewed. Asia’s position: the clause doesn’t belong in terms as proposed; language clause needed instead. Routed to Patrick.
  • 2026-03-07 15:30 ET — Japanese bilingual history idea developed into blog post proposal _blog-idea-language-teaching-at-baseworks.md. Routed to Patrick for review.
  • 2026-03-10 16:50 ET — Reminder (backup policy + voice guide) archived. Both items resolved or re-routed.
  • 2026-03-19 11:00 ET — All repos renamed to main. Both Mac Mini and MacBook Air confirmed on main tracking origin/main.
  • 2026-03-12 15:00 ET — QMD no_embed exclusion replicated on MacBook Air.
  • 2026-03-10 (no time) — French transcripts imported: Sarah Choukroun and Any Guay (fr-fr). Completed.
  • 2026-03-05 23:30 ET — Backup policy (Backblaze B2) added to ~/.claude/CLAUDE.md on both Mac Mini and MacBook Air.
2026-03-19
2026-03-18
2026-03-14
2026-03-12
2026-03-09
2026-03-08
2026-03-07
2026-03-05
2026-03-04
2026-03-03
  • Session summary guidelines: “exit/release” rule + EQUATE in-form transitional position added. Guidelines
  • Inbox notification test via Slack confirmed working.

Completed

Section titled “Completed”
2026-04-10
2026-04-08
2026-04-07
2026-04-06
2026-04-05
2026-04-01
2026-03-25
  • 2026-03-25 — Writing Process + Voice Guide Structural Changes — informational, archived. Archive
  • 2026-03-25 — Voice guide v2.0 feedback patterns — informational, no action required, archived. Archive
  • 2026-03-18 16:45 ET — How to create and use Claude Code skills — informational, no action needed, archived. Archive