Development History: Workshop on Claude Code and Claude Desktop for Humanities Research

A record of decisions, pivots, and reasoning — not just what exists, but how it came to be.

Origins

The project started as a single file (start.md) — a rough seed plan for a 3-hour workshop introducing Claude Code and Claude Desktop to researchers at DISSINET (https://dissinet.cz), a computational humanities project at Masaryk University in Brno.

The initial plan was evaluated in the first working session. Key clarifications that shaped everything that followed:

• Audience: Non-programmers and light coders — historians, social scientists. Not developers.

• Presenter profile: A technical person who is also a humanities insider — someone who can code and wants to sell Claude Code to people who don't.

• Participant setup: All have Claude Pro and Claude Desktop installed. Claude Code is NOT pre-installed.

• Core of the workshop: Document work — PDFs, DOCX, XLSX, MD. This is the centre of gravity.

• Materials: Must be self-contained (usable after the workshop without the presenter).

• The "one takeaway": I can use Claude Code, not just Desktop — or at least I can use Desktop much better.

• Phases C and D deferred: Materials may exceed what fits in 3h; selection happens later.

Phase A development

First documents (conceptual foundations)

• A1.desktop-vs-code.md — written first as the core framing document. Later revised by the user to become a three-way comparison (Desktop / Cowork / Code) when Claude Cowork emerged as a relevant tool.

• A.issue.upload-dance.md — named an informal/colloquial concept (not an established term) for the friction of manual file upload cycles in Desktop. Named it to make it discussable.

• A.concept.under-the-hood.md — minimum necessary mental model: context window, agent loop, tools, CLAUDE.md. Written to answer "why does it behave like this?" without requiring technical depth.

• A.concept.agents.md — written because "agent" was in the A4 vocabulary list but deserved its own treatment. Covers the trust/supervision question directly, with a practical table. Key addition: the "never modify originals unsupervised" rule for archival researchers.

Settings and configuration

• A.setup.settings-local.md — prompted by discovering that the subagent for web research was being blocked (WebSearch not in the allow list of .claude/settings.local.json). Wrote the fix, then wrote the doc explaining the system. WebSearch and WebFetch were then added to the settings, enabling subsequent research agents.

Tool basics (written by the user in parallel)

• A2.desktop-basics.md, A3.code-basics-non-programmers.md, A4.conceptual-vocabulary.md, A5.shortcuts-daily-usage.md, A6.zero-coding-workflows.md — written during the same working sessions as the research agents were running.

• A.concept.global-vs-local.md, A.token.management.md, A.setup.windows-wsl.md — added by the user.

Document workflows

• A7.working-with-pdfs.md, A8.working-with-docx-xlsx.md, A9.markdown-project-memory.md, A.markdown-central.md, A10.claude-and-zotero.md — written covering the core document-centric workflows. A9 and A.markdown-central together make the case for markdown as the connective tissue of a Claude-assisted research project.

Real-world examples (internet research)

Three research agents were run: 1. First research agent (A11–A13): Initially failed because WebSearch was not permitted. After fixing the settings, ran successfully. Produced a rich report covering social scientists (Pepinsky, Hall, Cunningham, Messing/Tucker), DH scholars (Berry, Pollin/DHCraft), and practical examples (Torres, Parrott/Every). Key finding: David Berry (DH humanities scholar, no programming background) built a research tool in 18 days using Claude Code — the flagship non-programmer example. 2. Note-making and reading/writing workflow research: Found the Obsidian+Claude Code ecosystem (Gao, Konik, Brier/Every podcast), Zotero+Claude workflows, Mark Carrigan's highlights analysis (best entry point for H/SS researchers), Benjamin Breen's honest historian's assessment (1 error per line in 18th-century paleography). Key tension identified: Claude's voice contaminating notes — "reading mode not writing mode" (Brier) as the sophisticated position. 3. Journal and funder policies: Found the policy vacuum at GAČR and AVČR; Horizon Europe's mandatory disclosure in 2025 forms; the convergence of all major publishers on the same framework; OUP as the outlier (strictest).

Critical perspective

• A.critical.limitations.md — written from the research findings. The Pepinsky "execution vs. interpretation" distinction became the organising framework. The 34% overconfidence statistic (models are more confident when wrong) is the single most striking fact for academic audiences. The qualitative research caution addresses interview-based and ethnographic work directly.

Adjacent tools and additional items

• A.adjacent.gemini, A.adjacent.tools, A14.skills-for-researchers.md, A15.agent-personalities.md, A16.personal-life-management.md, A.obsidian-logseq.md — written by the user.

Context scope

• A.issue.context-scope.md — added to address a gap between A.token.management (technical limits) and A.concept.under-the-hood (the mechanics). Neither covered the decision question: what should you include, why, and what breaks when you get it wrong. Organised around the framing effect of context (it does not just inform, it shapes what Claude thinks the task is), the "too much" crisis states (hypothesis confirmation bias, attention dilution, voice contamination, CLAUDE.md bloat), the "too little" crisis states (generic outputs, wrong constraints, misaligned problem-solving), and a CLAUDE.md scope guide built around the "manager's briefing" test.

Privacy and security

• A.issue.privacy-security.md — added after reviewing the existing materials: privacy/security was scattered as warnings across five files but never given a primary treatment. The document centres on data flow understanding rather than a compliance checklist: once you know where data goes in each tool mode (Desktop → Anthropic cloud; Code → Anthropic API, no training; e-Infra → on-premise), all decisions follow naturally. Covers: the Desktop/Code/e-Infra comparison, decision matrix by data type, agentic risks (.env files, unintended file reads, .claudeignore), GDPR framing for EU researchers, and MUNI's binding data security rules.

Key structural decisions made along the way

The linking convention

After enough docs existed, the decision was made to add ## Related sections to every document — linking to conceptually connected docs by filename. Rationale: when Phase D1 builds the GitHub Pages site with a network visualisation, these links become the edges of the graph automatically. All existing docs were retrofitted; new docs include Related sections from the start.

The D1 decision (GitHub Pages with network visualisation)

Added as Phase D1 — not just a static site but one with a network map as the entry point, where nodes are topics/docs and edges are conceptual connections. The network serves double duty: navigation for the site and potential opening slide for the workshop.

The E phase (mini-books)

Added after the main A/B material was substantially in place. Two audiences:

• E1 (scholars): Peer-to-peer tone. The CUNI/MUNI guidelines + journal/funder policies give it a regulatory backbone. CUNI researcher recommendations PDF (co-authored by MUNI, freely distributable) is the key institutional document.

• E2 (students BC/MA/PhD): Central theme: "You need to own the result." This framing was chosen over rule-based framing because it is practical, non-moralistic, and scales across all three degree levels without changing the principle. It also explains why disclosure matters (you can't disclose what you don't understand) and handles both failure modes (over-delegation and under-use).

The regulatory research

Three sets of policies documented: 1. E.muni-guidelines.md — MUNI's non-binding recommendations (2023). Key gap: no researcher/publication policy; no AI provisions in the binding Study and Examination Regulations. 2. E.cuni-researcher-recommendations.md — CUNI researcher PDF (2 pages, freely distributable, co-authored by MUNI). The best available Czech researcher guidance. Retrieving it required: fetching the CUNI portal → finding the PDF link → using the Read tool to parse the downloaded PDF (WebFetch could not decode the compressed binary). 3. E.journal-funder-policies.md — Full publisher matrix. Key findings: GAČR has no AI policy; Horizon Europe has mandatory disclosure in 2025 forms; all major publishers converge on the same five rules; Elsevier's declaration format is the safe baseline.

Technical setup notes

• Working directory: /mnt/c/Users/D/Documents/GitHub/claude-personal/lecture/

• Settings file: .claude/settings.local.json — WebSearch and WebFetch were added during the session to enable background research agents.

• Research agents: Multiple background agents used for web research. Agent pattern: launch with run_in_background: true, get notified when complete, save raw findings as -raw.md files, write synthesis docs from findings.

Current state (March 2026, session 1)

Meta-documents: _history.md (this file) and _ownership.md added. _ownership.md applies the B.ownership.md framework to the project itself — four modes of collaboration documented, per-document attribution, overall ownership table, and a disclosure statement suitable for publication. The note at the end flags that _ownership.md is itself a Mode 2 product and asks the user to verify its accuracy.

Phase A: Substantially complete. All planned A-docs exist. All have ## Related cross-links. Two meta-docs added at close of session: _history.md (this file) and A.markdown.history.md (teaching doc on the value of project history files — the history file practice itself as workshop content).

Phase B: B.usecases.md written with 8 full scenario sketches. Scenario 6 (folder of 40 PDFs) flagged as the core live demo. B.experience.md added: the experiential/psychological dimension of working with AI — control and ownership axis, positive states (joy, curiosity, flow), difficult states (overwhelm, anxiety, FOMO), real vs. anxiety-driven productivity, work-life balance dynamics, and the authenticity question ("is this still my work?"). B.ownership.md added: operationalises the ownership question from B.experience — dimensions of contribution (ideas, structure, evidence, language, evaluative judgement), what Claude can and cannot honestly assess about its own role, practical review prompts (basic, by dimension, devil's advocate), and connection to disclosure requirements.

Phase C: Not yet started (deferred by design — requires selection from Phase A material).

Phase D: D1 planned (GitHub Pages + network visualisation). Not yet built.

Phase E: Plans written. Reference documents complete (MUNI, CUNI, journal/funder policies). Mini-books not yet drafted.

Session 2 — 2026-03-14

A second working session identified and filled several conceptual gaps, primarily in the area of model selection, memory, personalisation, team configuration, trust, and prompting.

New A-level documents

A.issue.model-selection.md — when to use Sonnet vs Opus vs Haiku. Gap identified: the project covered Claude Code extensively but never addressed model choice as a practical decision. Core argument: Sonnet is the right default; Opus is worth switching to for hard interpretive tasks and subtle language judgment; Haiku is only relevant for high-volume simple tasks on API billing. Includes the quota angle (Opus burns usage faster) and a quick-reference table by task type.

A.concept.memory.md — Claude Code's built-in Memory system as a distinct concept. Gap identified: the project treated CLAUDE.md as "the memory mechanism," collapsing two fundamentally different things. The key distinction: CLAUDE.md is user-written, Claude reads it; Memory (~/.claude/MEMORY.md) is Claude-written on the user's behalf, Claude reads it. Memory is the only Claude Code persistence mechanism where Claude is the author. Covers ~/.claude/MEMORY.md, the /memory command, what belongs in Memory vs. CLAUDE.md, maintenance/pruning, and the authorship trust note.

A.issue.personalisation.md — the full personalisation system as a whole. Gap identified: individual components (CLAUDE.md, skills, memory) were each covered, but no document mapped the complete system or named the two-layer distinction. Introduces: (1) Claude Code mechanisms layer (CLAUDE.md, Memory, Skills, Hooks, MCP — the technical infrastructure), and (2) Project accountability files layer (_history.md, _ownership.md, progress.md — markdown files maintained about the project, not instructions to Claude). The second layer was almost entirely absent from prior material. Includes a step-by-step sequence for building the setup deliberately and a quick diagnostic of under-configuration symptoms.

A.issue.team-claude.md — team sharing and export of Claude configuration. Gap identified: personalisation was framed entirely around a solo researcher; the shareable nature of project-level configuration via git was mentioned only in passing (one sentence in A14, one in A.markdown.history). Core argument: anything in ~/.claude/ is personal and never shared; anything in the project folder can go in git and is shared automatically on clone. Covers the team baseline concept (committed CLAUDE.md + shared .claude/commands/ as shared methodological infrastructure), the settings.json vs settings.local.json distinction for team permissions, onboarding a new team member, moving a personal setup to a new machine, and the personal/shared tension (personal preferences must not end up in the shared project CLAUDE.md).

A.issue.bounding.md — how to define and scope a task for Claude. Gap identified: this is distinct from A.issue.context-scope (what information to include) — bounding is about the task definition itself, not the information selection. Core concept: a well-bounded problem has clear edges (what is inside and outside the task) without predetermining the answer. Introduces the spectrum from underbounded (open brief producing something plausible but not what was needed) to overbounded (answer disguised as a question, producing hypothesis confirmation). The central organising framework: everything in a prompt falls into necessary (task verb, constraints Claude can't infer, success criteria), misleading (expected answer, emotional stake, prior conclusions alongside fresh material), or unnecessary (anything already in CLAUDE.md/Memory/session, field background, pleasantries). Covers decomposition of complex tasks as the researcher's intellectual work — where ownership is established or lost — and the "state your understanding" pre-flight check.

New B-level document

B.trust.md — trust as a relationship property, not a tool property. The conceptual framing was provided by the user: trust is not about hallucinations alone but about having a trustworthy relationship built through knowledgeable control of information scope, verification checkpoints, and project infrastructure as epistemic architecture. The document reframes the central question from "is Claude reliable?" to "have I created the conditions under which Claude's output can be trusted for this specific task?" Three dimensions: accuracy (the hallucination dimension), scope alignment (did Claude address the actual question?), and epistemic transparency (can you explain and reconstruct how the output was produced?). Key argument: project infrastructure (CLAUDE.md, skills, history files) is trust infrastructure — it determines whether the conditions that produced any output can be audited and reconstructed. Covers trust calibration by task type, trust degradation over time (long sessions, stale infrastructure, confirmation accumulation), and team trust conditions.

Conceptual trajectory of session 2

The session developed a cluster of interconnected concepts that were implicit in the earlier material but not made explicit:

• Personalisation as a system with two layers (Claude Code mechanisms + project accountability files)

• Team configuration as shared epistemic infrastructure via git

• Trust as a property of a designed relationship, not a tool feature

• Bounding as the prompt-level complement to context scope — task definition, not information selection

These four documents form a coherent group and should be considered together in Phase C selection decisions. They represent a shift in the project's centre of gravity from "how to use Claude" toward "how to use Claude well — systematically, verifiably, and with maintained intellectual ownership."

Session 3 — 2026-03-16

A third working session extended the B-level conceptual material (autonomy, team AI, full lifecycle), added the Zotero MCP setup guide and skills ecosystem overview, sharpened two existing documents based on critical reflection, and installed the first project-local Claude skills.

New B-level documents

B.autonomy.md — how to use AI across a sustained research project without losing intellectual autonomy. Covers the autonomy paradox (AI can increase autonomy when calibrated correctly), the six mechanisms of erosion (epistemic capture, atrophied judgment, agenda drift, confirmation accumulation, voice homogenisation, peer substitution), detection signals, good practice, and DISSINET-specific risks (interpretive authority over primary sources, anomalous source patterns, corpus scale, inter/transdisciplinary dimension). Key framing: the peer group — not any individual or tool — is the final calibrator of intellectual autonomy.

B.team-ai.md — AI in collaborative research work. Introduces the "third-party problem": when a team member uses AI, they bring an additional actor into the collaboration that others cannot directly observe. Two failure modes: transparent pass-through (raw AI output shared as AI output) and opaque encapsulation (AI output presented as one's own with no signal). The productive middle: shared AI-assisted work with documented provenance. DISSINET section grounds the analysis in the actual team culture: Slack + GDocs collaborative workflow, strong norm of sharing drafts, co-author subteams, explicit co-authorship rules, inter/transdisciplinary respect culture, negotiation/attunement as the collaborative mode. The "Claude said, maybe check this" note in a GDoc comment is the worked example of transparent flagging done right.

B.lifecycle.md — master document for AI across the full research lifecycle. Core argument: the "programmer model" (well-defined task, external verification) can be extended across the whole lifecycle, but only if you understand the engineering-like vs. interpretive gradient and calibrate accordingly. Includes the iterative/non-waterfall framing (with feedback loop diagram showing every phase generating return signals to earlier phases) and the claim that AI enables more agile research — not just faster research — by tightening the feedback loops that redirect work.

B.lifecycle.0.iteration.md — the foundational principle: fail quickly and let it be documented. Contrasts Model 1 (try not to fail, conceal when you do) with Model 2 (expect failure, discover it early, treat it as data). Covers the cost curve of failure (the same problem costs exponentially more to discover at manuscript vs. question formation stage), scaffolding the micro-discovery loops (before/during/after each phase), the pre-mortem as structured anticipation, documentation infrastructure, and the cultural dimension (academic culture runs on Model 1; AI enables but does not automatically produce Model 2).

B.lifecycle.1–5.md — five phase documents covering research question formation, literature engagement, data capture, data analysis, and manuscript writing. Key contributions: the centroid problem (creativity phase), the finding/synthesizing/interpreting distinction (literature), the micro-discovery loop as the primary AI contribution to data capture, the execution/interpretation boundary and qualitative coding complications (analysis), and the 5↔1 feedback loop connecting manuscript writing back to research question formation through the practice of proposal writing — even internal proposals — as thinking tools.

New A-level documents

A.setup.zotero-mcp.md — step-by-step installation of zotero-mcp (54yyyu/zotero-mcp) for connecting Claude to a local Zotero library. Two paths: Path A (Windows native for Claude Desktop, using uv) and Path B (WSL for Claude Code, using web API mode). Path B required the web API workaround because of an unresolved bug: zotero-mcp running inside WSL2 cannot reach Zotero on the Windows host via localhost. This WSL2/localhost network boundary issue is documented as a known, unresolved bug.

A.skills-ecosystem.md — overview of the Claude skills ecosystem for researchers. Discovery channels, the document foundation skills (pdf/docx/xlsx/pptx), the K-Dense scientific skills collection (175 skills, MIT), and the Imbad0202 academic pipeline (multi-agent, Max plan). Lifecycle-mapped skill selection. The key addition from community sources: the best skills are the ones you create — encode your own working methods into skills via the skill-creator tool. Also: the distributional convergence problem (why skills matter: models default to the statistical centre), the context window cost warning (3–5 skills maximum), and a full "Creating your own skills" section with DISSINET-specific examples (source extraction, style-matching, grant section, multilingual abstract, annotation scheme).

A.literature-discovery.md — practical workflow document assembling the search stack for literature discovery. The gap: no single prior document showed how Gemini Deep Research, Claude Code database skills, Elicit, and Research Rabbit chain together. Covers: the tool landscape by task, Gemini Deep Research as the web entry point, the honest answer on Gemini-Claude technical integration (workflow-based, not technical; Weizhena and Imbad0202 as in-Claude equivalents; Google MCP as a future possibility), K-Dense database skills for systematic academic search (openalex-database, literature-review, arxiv-database), the 6-step discovery workflow ending in Zotero capture and Claude synthesis, and the verification rule.

Document revisions

A.concept.agents.md — added Oh My OpenAgent (ohmyopenagent.com) as a concrete anchor for the far end of the supervision spectrum. The system's "zero intervention, full autonomy" (ulw command, Sisyphus/Prometheus/Hephaestus agents) makes the researcher-appropriate supervision modes clearer by contrast. Explicit framing: the decisions being automated in full orchestration are ones that require research judgment, not just instructions.

B.lifecycle.md (two revisions): 1. Elevation of B.lifecycle.0.iteration — the foundational "fail quickly" principle was separated from the five sequential phases at the top of the document. It now reads as the frame that runs through all phases, not a peer item in a flat list. 2. Sharpened "two fragile moments" — added the three-part condition that makes creativity and literature finding distinctively dangerous: AI actively misleads + hard to detect + damage compounds downstream. Contrasted with other phases where the fragility is visible or the researcher knows they are interpreting. The other three phases (data capture, analysis, manuscript) restructured as clearly-labelled brief pointers rather than equal-weight "fragile moments."

First project-local skills

Remotion (remotion-dev/skills → remotion-best-practices) and Excalidraw (coleam00/excalidraw-diagram-skill → excalidraw-diagram) installed as project-local Claude skills. Node.js installed via fnm to enable npx skills. The correct Remotion repo (remotion-dev/skills) differed from the command in the source article (remotion/agent-skills). Both skills committed to the repo under .agents/skills/ with symlinks in .claude/skills/ — available to anyone who clones the repository.

README.md created

First public-facing entry point for the repository: audience/pitch, file structure map, curated reading map by theme (orientation, document work, setup, researcher perspective, critical), key concepts table, authorship disclosure summary with pointer to _ownership.md, and project status.

Conceptual trajectory of session 3

Session 3 completed the B-level conceptual layer: autonomy, team dynamics, and the full research lifecycle now all have primary documents. The session also introduced the first reflective revisions — returning to existing documents to sharpen arguments that had been underspecified (the "two fragile moments" rationale, the iteration principle's prominence). The skills work (ecosystem document, installed skills) begins to make the materials self-demonstrating: the project that teaches about skills now has skills.

Session 4 — 2026-03-16

A fourth working session added NotebookLM integration as a demonstration artifact, created the Excalidraw lifecycle schema, produced four new substantive documents (slack workspace, epistemics, dangers map, centroid-periphery navigation), and completed cross-linking and navigation document updates.

NotebookLM integration and Excalidraw demo

NotebookLM artifact generation: Created a NotebookLM project "Claude as Research Assistant" with all root-level markdown files as sources. Generated and downloaded three artifacts: notebooklm-infographic.png ("AI Research Workflow Blueprint"), notebooklm-slides.pdf ("The AI Research Workbench"), notebooklm-podcast.mp3 ("Claude Code for Rigorous Academic Research"). Added to repo and highlighted in README.md under a new "Work in progress" section. Notable technical issue: background agent launched for artifact waiting lacked Bash permissions; handling done directly in main conversation sequentially.

research-lifecycle.excalidraw + research-lifecycle.png — Excalidraw diagram of the 5-phase research lifecycle using the project-local excalidraw skill. Visual language: phases 1–2 in red (fragile — AI actively misleads) with ⚠ FRAGILE warning labels; phases 3–4 in blue (engineering-like, productive); phase 5 in green (manuscript as synthesis). Forward arrows on the left spine, feedback arcs on the right (dashed arrows from phase 5 back to phases 2, 3, 4; solid green arc back to phase 1). Technical fix: initial render showed text overflow in phase description lines; resolved by shortening to fit 280px boxes.

New A-level document

A.issue.slack-workspace.md — Slack as a team worktable for Claude. Covers the core problem (team knowledge accumulates in Slack, invisible to Claude by default) and two workflow patterns: (1) copy-paste as .txt files under notes/_slack-YYYY-MM-DD-topic.txt (low-threshold, selective consent); (2) Slack MCP server (@modelcontextprotocol/server-slack) for full programmatic access. Introduces the privacy/consent threshold as the key distinction between the two modes: copy-paste = researcher's own discretion; MCP = requires explicit team agreement. Four use cases mapped: workflow memory, onboarding new members, decision documentation, and synthesis of Slack discussions into structured documents. Backlinked from B.team-ai.md.

New B-level documents

B.epistemics.md — epistemic risks from AI-assisted research: a category distinct from factual failure (hallucination) and skill erosion (B.autonomy). Four interlocking risks: (1) Sycophancy — RLHF structural tendency toward approval over truth; the sycophancy ratchet (compounds across sessions via confident framing accumulation); (2) Confirmation loop — sycophancy at project timescale: working hypothesis in CLAUDE.md → confirmations each session → refined hypothesis encoded → stronger confirmation next round; no visible failure, increasing certainty is the warning sign; (3) Tunnel effect — Claude operates within the frame the researcher provides; cannot say "your question is wrong" or "you are asking the wrong question"; most dangerous in literature synthesis; (4) Team-level groupthink — shared CLAUDE.md + shared hypothesis = same sycophantic tendency running in parallel for each team member; correction mechanism (peer challenge) disabled precisely because the tool was configured to reduce friction. Five counter-practices: adversarial prompting in fresh session; multiple agents with different information contexts (standard/empty/inverted hypothesis); cross-model checking (Claude Code + Gemini CLI in two terminal windows over same repo — divergence is diagnostic signal, not winner/loser); team framing rotation; structural "what's not there" questions as closing routine.

B.centroid-periphery.md — reframes the "centroid problem" from a straightforward danger into a navigation challenge. Key conceptual move: the centroid is not the enemy — most research activity legitimately belongs near the center (synthesis, consolidation, applying standard methods), and AI is genuinely excellent at center-work. The danger is specific: involuntary centroid capture when doing frontier work. Three mechanisms of involuntary drift: (1) tractability drift — AI's cleaner formulation replaces rough peripheral intuition without a visible decision point; (2) confidence asymmetry — fluency ≠ correctness, but they feel identical; (3) invisible transition — "using AI to explore my idea" → "following AI's refinement" with no explicit handover. Navigation table maps 8 activity types to axis position and appropriate AI relationship. Practical habit: name your mode before opening Claude. Mode-switch rule: when moving from center to frontier within a session, explicitly change the AI relationship. Team dimension: make axis position explicit when sharing work. Updated B.lifecycle.1.creativity.md (softened centroid framing, added link), B.epistemics.md (backlink), C.dangers.md (renamed entry to "Involuntary centroid capture" to reflect the navigation nuance).

First Phase C document

C.dangers.md — summative map of all AI-as-assistant risks. Four categories: (1) output quality (hallucination, vibe research, scope misalignment, qualitative coding unreliability); (2) epistemic (sycophancy, confirmation loop, tunnel effect, involuntary centroid capture, literature finding fragility); (3) autonomy/capability (atrophied judgment, agenda drift, voice homogenisation, peer substitution); (4) structural/relational (data exposure, agentic risk, third-party problem, team groupthink, attribution failure). Core insight: detectability and severity do not track each other — hallucination is widely discussed because it is visible; confirmation loops and groupthink are rarely discussed because they feel like success. Detectability spectrum table ranks 13 risks from High to Very Low. Three compound risk combinations documented: sycophancy × project memory × team sharing; centroid × literature fragility; atrophied judgment × peer substitution. Cross-referenced to 12 source documents. Opening framing: "the most-discussed risks are not the most dangerous ones."

Cross-linking and navigation updates

Diagnostic grep confirmed 7 files referencing new documents at session end; the remaining gaps were:

• B.lifecycle.md — added links to B.epistemics and B.centroid-periphery in Related section

• B.trust.md — added link to B.epistemics (sycophancy/confirmation accumulation addressed in the body)

• start.md — added A.issue.slack-workspace to A section; B.epistemics and B.centroid-periphery to B section; opened Phase C with C.dangers entry and updated status from "deferred" to active

• _history.md — this entry

Conceptual trajectory of session 4

Session 4 marks the opening of Phase C. The first C document (C.dangers) is explicitly meta: it maps risks described across 12 A and B documents into a single view, organised around the insight that detectability and danger are not correlated. The two major B contributions (B.epistemics, B.centroid-periphery) both address the same underlying tension: how AI shapes the direction of thinking, not just the quality of individual outputs. B.epistemics covers the mechanisms (sycophancy, loops, tunnels); B.centroid-periphery covers the structural pull (toward what is known, expressible, trained-on). Together with B.autonomy (session 3), they form a coherent treatment of the long-term intellectual costs of uncritical AI use — a set of risks that are almost entirely absent from practical AI guidance precisely because they feel like productivity.

Session 5 — 2026-03-16

A fifth working session (continuing the same day as session 4) added personal experience cases, a plan mode document, and the project's maintenance infrastructure — CLAUDE.md, a project-local slash command, and a Stop hook.

New documents

_microcase.template.md — a template for collecting short personal experience cases from the talk. Four-part structure matching the microcase format: (1) the problem, (2) the challenge, (3) the solution, (4) the good / bad / ugly, plus a one-sentence takeaway. Each section has a leading question rather than a blank. The > blockquote markers serve as visible placeholders. Metadata fields capture researcher, lifecycle phase, and tools used.

B.TH.personal.use-cases.md — nine personal use cases from the presenter's own research work, digested, polished, and anonymized from raw notes in _TH.microcases.md. All personal names removed; project-specific names (Consolamentum, FFF) replaced with general descriptions derived from reading the actual project CLAUDE.md files in sibling directories. The nine cases, in order: (1) reviewing a technically unfamiliar dissertation; (2) quick orientation before a review meeting; (3) preparing a graduate course from scratch; (4) data analysis — scripts vs. direct conversation; (5) turning course outputs into a public article; (6) popularizing a published paper as a data snapshot; (7) building a research tool from scratch; (8) reviewing four related research projects for synergies; (9) building this workshop (meta-case). Closing section identifies four cross-cutting patterns: active reading through questions; the ownership doubt in almost every case; AI scales the doable without resolving what to do; bulk/structure/logistics cases vs. interpretation/direction cases.

A.issue.plan-mode.md — plan mode (Shift+Tab) as the built-in mechanism for separating proposal from execution. Covers: what it is, how to activate, when to use it, the researcher framing (irreplaceable data, supervision principle), the practical five-step pattern (describe → plan → review → approve → execute), and a note on plan mode as a natural interruption to the sycophantic completion dynamic. Connected to the supervision spectrum in A.concept.agents, the bounding distinction in A.issue.bounding, and the confirmation loop risk in B.epistemics.

CLAUDE.md — the project's context file for Claude Code. Covers: project overview, repository structure, naming conventions (A/B/C/E/B.lifecycle/B.TH/_), working conventions (Related sections, link format, root directory), and the trigger condition: "after any session that creates or substantially modifies documents, run /update-meta-docs."

.claude/commands/update-meta-docs.md — a project-local slash command invokable as /update-meta-docs. Gives specific instructions for updating each of the three meta-documents: _history.md (add a dated session entry matching prior style and depth); start.md (mark completed items ✓, add entries for missing documents); _ownership.md (attribute new documents to the correct collaboration mode). The command encodes what "update" means concretely so that the instruction in CLAUDE.md is actionable rather than aspirational.

.claude/settings.json — Stop hook that prints a reminder to run /update-meta-docs whenever Claude finishes a session. Paired with the CLAUDE.md trigger condition and the slash command, this forms a three-layer maintenance system: CLAUDE.md names the rule, the hook reminds at the right moment, the command does the work.

Document revisions

A.issue.personalisation.md — added a "builds as you discover" note at the end of Step 2 ("Each new project"). The note corrects a misleading implication in the existing advice: "start at day one" is right about the habit but wrong about content. CLAUDE.md, hooks, and the /update-meta-docs command for this project were created in session 4-5, after 50+ documents existed — not at project start. The project itself is cited as the concrete example. The reframe: "start at day one" means create the file and start it, even minimally; the content becomes accurate only once the project is understood.

B.lifecycle.md and B.trust.md — cross-links to B.epistemics and B.centroid-periphery added to Related sections. Both documents referenced the relevant concepts in their body text without linking to the primary treatment.

_index.md — an ~80-term concept-to-documents index covering all major themes across the A/B/C/E documents. Each entry has a one-line description and 1–4 document links, primary first. Nine theme groups: Tools and modes; Project infrastructure and personalisation; Critical limitations and output risks; Epistemic risks; Autonomy and long-term risks; Ownership and attribution; Research lifecycle; Team and collaboration; Privacy, security, and institutional. Serves three purposes: quick-search input for the GitHub Pages site; data source for the wiki hover feature (term → popup with relevant document links); term-level layer for the network visualisation that the Related section links alone cannot provide.

Conceptual trajectory of session 5

Session 5 closed two loops. The first: the personal cases document gives the B-level conceptual material its experiential grounding — the abstract risks described in B.autonomy, B.epistemics, and B.centroid-periphery are now traceable to specific episodes where they showed up. The second: the maintenance infrastructure (CLAUDE.md, command, hook) makes the personalisation advice in A.issue.personalisation.md self-demonstrating. The project that teaches about project-level Claude Code configuration now has project-level Claude Code configuration — created, as the "builds as you discover" note acknowledges, once there was enough project to configure.

Session 6 — 2026-03-17

A sixth working session implemented the D1 GitHub Pages site: a force-directed network visualisation as the entry point, with 66 generated document pages, a build script that extracts the graph from the existing ## Related links, and a term index from _index.md.

New infrastructure: build script and generated site

build/build.py — a single Python script that produces the entire docs/ output in two passes. Pass 1 scans all root .md files (skipping meta-docs and raw files), extracts titles, descriptions, and ## Related edges, and writes docs/network-data.json (66 nodes, 304 links) and docs/term-index.json (93 terms from _index.md). Pass 2 converts each document to HTML with python-markdown, rewrites internal .md links to .html, and wraps each in a shared page template (sticky nav bar with ← Map link + document title, <main> content, footer). The script uses filename prefix rules to assign category and node colour: A → blue, B → orange, B.lifecycle/B.TH → amber, C → red, E → green.

build/requirements.txt — single dependency: markdown>=3.4 (python-markdown). No further dependencies: the build is intentionally dependency-minimal.

docs/index.html — hand-written entry point. Loads network-data.json via fetch(), renders a full-viewport WebGL force-directed graph using the force-graph library (CDN, ~80KB). Nodes are coloured by category; click navigates to the document page; hover shows a tooltip (title + first sentence of description + category label). Canvas-painting node labels appear only when zoomed in (globalScale ≥ 1.2). Contains a <div id="guidance-panel" class="hidden"> slot reserved for the Phase C guidance panel (v2). Error state displays a friendly message directing to python build/build.py.

docs/style.css — shared styles for both site pages. Two distinct visual modes: body.map-page (dark background, fixed header, full-viewport canvas, tooltip positioning) and body.doc-page (light background, sticky nav bar, 740px centred content with full typographic treatment for tables, code blocks, blockquotes, headings). Responsive breakpoint at 600px hides the legend and tightens document padding.

docs/network-data.json and docs/term-index.json — generated outputs. Not committed to git directly (regenerated by the build script); documented in CLAUDE.md as generated.

docs/*.html (66 pages) — generated document pages, one per content document.

Technical decisions recorded

Library choice: force-graph (single-file WebGL, ForceGraph()(el).graphData({nodes,links}) API) over D3 — simpler initial API, pan/zoom/drag built in, no manual SVG management required. D3 noted as an alternative if more visual customisation is needed later.

Edge deduplication: Related sections are directional in the source markdown (A links to B, B links to A in separate files), producing duplicate edges. The build script deduplicates by frozenset of source/target pairs, keeping the first occurrence. This produces 304 undirected edges from ~420 raw directional link extractions.

Description extraction: The tooltip description uses the first non-metadata paragraph from each document. A regex skips lines of the form **Label:** (bold text ending with colon before the bold-close markers) — the common "Status:", "The problem:", "Who this is for:" patterns used across documents as structural metadata. This gives clean first-sentence descriptions in most cases.

Document revisions

start.md — D1 section rewritten from an open question + planning notes into a completed implementation record: exact file counts, tech stack choices, v1 feature list, and v2 backlog. The "Open questions" items that D1 answered (auto-derived edges from Related links, click-to-navigate, full landscape) are resolved implicitly.

CLAUDE.md — two lines added to the repository structure section: build/build.py (run to regenerate) and docs/ (generated output, do not edit manually).

Conceptual trajectory of session 6

The ## Related linking convention established in session 1 — added to every document specifically so that "Phase D1 builds the GitHub Pages site with a network visualisation" — has now paid off. The entire graph structure was already latent in the documents; the build script simply extracted it. No manual edge curation was required. This confirms the design decision: consistent link formatting throughout the authoring phase makes the navigation layer automatic at build time. Session 6 also establishes the maintenance workflow: re-running python build/build.py regenerates the full site; the docs/ folder is treated as generated output that is never edited directly. The site is now a deployable artifact — GitHub Pages activation (repo Settings → Pages → docs/ folder) is the only remaining step to make the materials publicly accessible.

Session 7 — 2026-03-17

A seventh working session (continuing the same day as session 6) refined the GitHub Pages network visualisation through a sequence of iterative UI improvements and fixed a build bug that was causing broken internal links, then extended the .claudeignore coverage in the privacy document.

Bug fix: broken internal links in generated pages

Root cause identified and fixed in build/build.py: The link-rewriting regex captured the filename stem (everything before .md) into group 2. The lambda then called slug() on that stem — but slug() uses os.path.splitext(), which splits on the last dot. So A.concept.agents (already stripped of .md) was further stripped to A.concept (losing .agents). Every internal link to a dotted filename produced a 404. Fixed by replacing slug(m.group(2)) with m.group(2) directly — the regex already did the stripping.

Network visualisation: iterative UI refinements

The session worked through several rounds of label and highlight design, each prompted by visual inspection:

Label decluttering (three iterations): 1. Zoom threshold raised to 2.5 — the original threshold of 1.2 fired all 66 labels simultaneously at near-default zoom; raising to 2.5 deferred them but did not solve density at that level. 2. Hover-reveals-neighbors mode — replaced zoom-threshold labels entirely. hoveredNode state variable tracks the currently hovered node; neighborMap (adjacency set built from data.links before graphData() is called) identifies direct connections. On hover, the hovered node and all its direct neighbors get labels drawn on the canvas; all other nodes are unlabelled. Hovered node: bold white label; neighbors: lighter, smaller. Works at any zoom level. 3. Animation loop fix — hover-based labels initially stopped working after ~30 seconds: force-graph pauses its animation loop once the physics simulation cools, so hoveredNode updates were not reflected in the canvas. Fixed by adding .autoPauseRedraw(false) to the graph chain, keeping the canvas rendering at 60fps regardless of simulation state. A prior attempt to fix this with Graph.refresh() failed because it triggered only a single repaint; autoPauseRedraw(false) keeps the loop continuous. Also fixed a SyntaxError introduced during iteration: const isHovered and const isNeighbor were declared twice in the same function scope (once in the border block, once in the label block), killing the entire script silently.

Node highlight: yellow border: The hovered node and its neighbors get a yellow stroke ring drawn before the node circle. Hovered node: #ffe44d (bright yellow), 1.5px, radius r+2.5; neighbors: #ccb800 (gold), 1px, radius r+1.5. Simple ctx.stroke() — no gradient, minimal CPU cost. Replaced an earlier radial-gradient halo approach that the user found too resource-intensive.

Active node: green ring: activeNodeId tracks the slug of the document currently loaded in the detail panel. A green ring (#4cde80, 2px, radius r+3.5) is drawn on that node's canvas paint. Set in openDetail(), cleared in closeDetail(). Coexists with the yellow hover border.

Split-screen detail panel: Clicking a node on wide screens (≥900px) now opens the document in a right-hand panel (50% width) rather than navigating away. The panel contains an <iframe> loading the document HTML, a close button (✕), and an ↗ full page link. The ← Map link inside the iframe is intercepted to close the panel instead of reloading the page. The graph resizes to fill the left half when the panel opens and restores to full width when closed. On narrow screens (<900px), clicking navigates away as before.

Force physics tuning: Default d3-force parameters produce a hairball layout. Adjusted: charge strength −300 (10× default repulsion), link distance 70 (vs 30 default), link strength 0.3 (vs 1.0), d3AlphaDecay 0.01 (slower cooling → better minimum), d3VelocityDecay 0.25 (less damping → nodes travel further to natural positions). Result: clearer subcommunity separation.

Document revision

A.issue.privacy-security.md — the one-sentence .claudeignore mention (line 77) expanded into a full section. Added: a concrete example .claudeignore file with four annotated categories (credentials/secrets, raw personal data, unrelated personal material, embargoed/under-review work); three researcher-specific use-case scenarios; the key conceptual distinction between .claudeignore and .gitignore (independent mechanisms — sensitive files often need to appear in both). The gap this fills: the existing treatment named the tool without showing researchers what to put in it or when to use it.

Git commit

First commit of the D1 infrastructure: 78 files, 15,402 insertions. Included build/, docs/, updated meta-docs, _microcase.template.md, .gitignore (added clutter*.jpg, _sources/, .obsidian/).

Conceptual trajectory of session 7

Session 7 is primarily a craft session — the intellectual content was established in sessions 1–6; session 7 made it usable. The sequence of iterative fixes (label threshold → hover-reveals-neighbors → animation loop → SyntaxError → autoPauseRedraw) illustrates the standard trajectory of frontend work: each fix exposes the next issue. The .claudeignore expansion is the session's one conceptual addition: it completes the privacy document's treatment of the agentic risk from "here is the tool" to "here is how to use it and why it is distinct from the tool you already know." The session closes with the first git commit of the entire D1 stack — the site is now version-controlled and one GitHub Pages settings toggle from being publicly accessible.

Session 8 — 2026-03-17

An eighth working session (continuing the same day as session 7) introduced the adoption spectrum as a new conceptual axis for the project — the first document to explicitly position researchers on a continuum of AI integration — and produced a companion action guide mapping what each transition requires.

New B-level document

B.adoption-spectrum.md — From occasional query to orchestrated workflow: the spectrum of AI-assisted research. Five positions on a continuum, each defined not by technical skill alone but by the degree of structural integration between the researcher and the AI tool. Level 0: occasional querier (one-off web chat, no memory, treated as a search engine). Level 1: regular conversation partner (habitual use, prompting instincts forming, largely episodic sessions). Level 2: context-aware collaborator (persistent project context via CLAUDE.md or Claude.ai Projects, working on actual files, calibrated sense of Claude's limits — identified as the key conceptual jump). Level 3: workflow integrator (repeatable AI-assisted workflows, Claude Code for file-heavy tasks, explicit decisions about when not to use AI). Level 4: agent orchestrator (multi-step autonomous processes, API scripting, human role shifts to specifying and reviewing). Key argument: the spectrum is about structure, not skill — a researcher who can write sophisticated prompts but has no persistent context is still at Level 1. Includes sections on the uneven risk distribution across levels (epistemic risks peak at 2–3; agentic risks appear only at Level 4) and an explicit statement that Level 2–3 is the correct target for most humanities researchers.

New C-level document

C.leveling-packages.md — What to understand, try, and do: a transition guide for the adoption spectrum. Four packages, one per transition (0→1, 1→2, 2→3, 3→4), each with three parts: the conceptual shift (what mental model needs to update before the new level works), the first experiment (one concrete low-stakes action), and the practice (habits to sustain once arrived). The 1→2 package is the most developed: it centres on the uncomfortable act of articulating your own work to a non-expert as a research activity in its own right, gives a specific "30-minute project description" exercise, and names counter-confirmation as a required practice (not a nice-to-have). The 2→3 package introduces "false systematicity" as the characteristic risk: repeatable workflows create an impression of rigour that the underlying AI outputs may not warrant. The 3→4 package is explicit about the threshold: this level requires programming skill, and if that isn't available, Level 3 is the right plateau. Closes with "you don't have to level up" — a short section that defuses FOMO-driven escalation by naming it.

Conceptual trajectory of session 8

The session adds a new axis to the project's map. The prior B documents covered risks (B.autonomy, B.epistemics, B.centroid-periphery), workflow (B.lifecycle), collaboration (B.team-ai), and experience (B.experience, B.ownership, B.trust) — but none situated researchers on a scale of integration depth. The adoption spectrum fills that gap: it is the document a first-time reader needs to know where they are before the rest of the material makes sense. The leveling packages document is the actionable complement — it converts the spectrum from a taxonomy into a guide. Together they form a natural entry sequence for the workshop: where are you now, what does moving forward require, and what is the honest target? The explicit "Level 2–3 is exactly right" framing also does political work inside the workshop context: it gives non-programmers a defensible plateau and names the cultural distortion (toward Level 4 as the impressive destination) that might otherwise leave them feeling behind.

Session 9 — 2026-03-17

A ninth working session (continuing the same day as session 8) completed the C-level extraction documents and opened Phase D with the first participant-facing workshop materials.

New C-level documents

C.why.md — Why bother: motivations for AI-assisted research. A curated reference list of reasons to try AI assistance and reasons to level up on the adoption spectrum, organised as scannable one-liners with brief context notes and document links. Part 1 covers reasons to start at all, grouped into four clusters: Time and cognitive load (dissertation review in 5 minutes, 40-PDF triage, grant sections, perpetually deferred institutional tasks); Thinking quality (Socratic partner, fast first drafts, literature synthesis from sources already held, stress-testing via adversarial prompting, pre-mortem); Capability expansion (qualitative pattern recognition at scale, multilingual support, batch extraction without programming, projects that wouldn't have started); and the counterintuitive Autonomy case (AI can expand autonomy when it returns execution time to interpretation, and the joy of difficult-becoming-easy is a legitimate gain). Part 2 covers the per-transition motivations (0→1, 1→2, 2→3, 3→4) in the same format. Closes with a deliberately brief section naming FOMO and competition anxiety as motivations that do not sustain adoption.

C.tasks.md — What you can do: tasks by adoption level. A practical reference card organised by adoption level (cumulative — each level adds to lower ones), with four categories: Level 1 (9 tasks available in any web chat with no setup), Level 2 (8 additional tasks requiring persistent project context), Level 3 (9 additional tasks requiring Claude Code and workflow design), Level 4 (5 additional tasks requiring programming skill). Each task entry specifies what AI does and what the human retains. Closes with an explicit "Tasks AI is not reliable for" section covering reliable literature finding, original research question formation, final interpretive judgment in qualitative analysis, and specialist philological translation — each with reasons and alternatives. The companion to C.why.md: that document answers "why"; this one answers "what exactly."

New D-level documents

d.plan.md — Workshop Plan: Claude Code for Humanities Researchers. The presenter's guide for the 2.5-hour workshop. Covers: pre-workshop checklist (7 items including GitHub team access, fallback PDF curation, demo machine preparation); complete block-by-block agenda with exact demo prompts and timing; and presenter notes on pacing risks and failure modes. Four blocks: Block 1 (40 min, frontal) — three-tier comparison demo, three scripted magic moments (40-PDF triage, grant with CLAUDE.md, DISSINET Latin source with project context), adoption spectrum self-placement; Block 2 (45 min, hands-on) — terminal basics crash course (4 commands), Git → Node.js → Claude Code → Obsidian installation with winget-primary / direct-installer fallback, 10-min buffer; Block 3 (20 min, guided) — clone the workshop repo, 4 guided exploration prompts, 5-min free exploration; Block 4 (35 min, independent) — project scaffolding with start.md template, PDF-to-markdown conversion, substantive analysis prompts, reading note creation, optional CLAUDE.md setup. Presenter notes explicitly flag: protect Block 4 from time compression; have fallback PDFs pre-converted on the demo machine; route WSL2 questions to A.setup.windows-wsl.md.

D.tutorial.setup.md — Setup Tutorial: Installing Claude Code on Windows. Participant-facing installation guide for Windows native installation, designed for non-programmers with no prior terminal experience. Opens with a 4-command terminal cheatsheet and a practice exercise. Five installation steps with winget as primary path and direct-installer fallback for each: Git (git-scm.com), Node.js LTS (nodejs.org), Claude Code (npm install -g @anthropic-ai/claude-code), first launch and API key authentication, Obsidian (optional). Critical note prominently placed: close and reopen PowerShell after Node.js installation or npm will not be found. Closes with a readiness checklist, a troubleshooting section covering the five most common failures (winget not found, npm not found, claude not found, login failure, admin rights), and a one-paragraph WSL2 sidebar pointing to A.setup.windows-wsl.md.

D.tutorial.firstproject.md — First Project Tutorial: Explore, Then Build. Participant-facing hands-on guide in two parts. Part A: clone the workshop repo, open in Claude Code, work through 4 guided prompts (project orientation, document explanation, personalised reading recommendation, cross-document risk question), then free exploration. Part B: create a new project directory with git init, generate start.md either via Claude dialogue or verbatim template, run an improvement dialogue, copy PDFs in, convert to markdown, ask substantive questions (overview, connections, gaps), create a reading-notes.md with explicit instruction that editing it is part of the exercise, optional CLAUDE.md creation as the Level 2 transition moment. Closes with a "What to do next" section pointing to the three C documents and naming the single most useful post-workshop action (the 1→2 leveling package).

Update to workshop duration

The workshop was restated as 2.5 hours (150 minutes) in this session, down from the original 3h estimate. The agenda in d.plan.md is designed for 150 minutes with one 5-min break.

Conceptual trajectory of session 9

Sessions 1–8 built the project's conceptual and reference layer — risks, workflows, lifecycle, epistemics, ownership, the adoption spectrum. Session 9 is the first session oriented entirely toward the workshop participant rather than toward completeness of coverage. The two C documents (C.why.md, C.tasks.md) are extraction documents: they synthesise the existing material into the two entry-level questions a skeptical researcher would ask before reading anything else. The three D documents are the first participant-facing materials: instructions a non-programmer can follow alone, without the presenter. This shift from "building the material pool" to "designing the participant experience" marks the transition from Phase C to Phase D. The session also answers a structural question that had been open since session 1: what does the workshop actually look like? d.plan.md gives it a concrete form — four blocks, 150 minutes, one installation, one project started, one task completed.

Session 10 — 2026-03-17

A tenth working session (continuing the same day as session 9) made two passes at the existing documents: first updating the workshop installation instructions to match Anthropic's current recommended method, then systematically integrating guidance from the official Claude Code best-practices documentation into the A-docs and lifecycle documents where it was most relevant.

Installation method update

D.tutorial.setup.md — the Node.js installation step and npm install -g path were replaced with Anthropic's current recommended Windows install method: a single PowerShell one-liner irm https://claude.ai/install.ps1 | iex. This script installs Claude Code and all dependencies without requiring Node.js as a precondition. The WinGet fallback (winget install Anthropic.ClaudeCode) was retained with a note that it does not auto-update. The security-policy fix (Set-ExecutionPolicy) was added to the troubleshooting section. The Git installation step was retained as the only remaining prerequisite. An official documentation link (code.claude.com/docs) was added to the Related section.

d.plan.md — Block 2 installation instructions updated to match: the Node.js step removed, the PowerShell one-liner substituted, the fallback section rewritten. Official documentation link added to Related.

Best-practices integration

After fetching and digesting the official Claude Code best-practices documentation (code.claude.com/docs/en/best-practices), targeted additions were made to five existing A and B documents. The selection principle was: include content that is both actionable for researchers at workshop level and not already covered anywhere in the project's document set.

A9.markdown-project-memory.md — three additions. First: a new section before "What to put in CLAUDE.md" covering the /init command (inspects a folder and produces a first-draft CLAUDE.md) and the alternative "Ask me 5 questions about my research" dialogue approach. Second: a do/don't include table distinguishing what belongs in CLAUDE.md from what should be left out — encoding the "too long is as bad as too short" principle as a concrete binary. Third: the @path/to/file import syntax, which allows CLAUDE.md to pull in content from other files (convention files, style guides, name variant tables) without copying — useful for separating stable conventions from project-specific context. Official docs reference added before Related.

A.issue.plan-mode.md — a new opening section before "How to activate it" names and structures the four-phase workflow from the official best practices: Explore (gather context in plan mode, no action) → Plan (propose and negotiate the approach) → Implement (execute approved plan) → Commit (document the endpoint). This gives plan mode a formal frame beyond the on/off toggle it was previously reduced to. The Ctrl+G shortcut (open the plan text in an external editor for precise annotation) was added — a capability not previously mentioned anywhere in the project. Official docs reference added.

A5.shortcuts-daily-usage.md — /rewind added to the slash commands table with a full explanatory note. The key concept: every Claude Code action creates a checkpoint; /rewind restores conversation state and project files to a prior checkpoint. Framed for researchers as "undo for Claude Code sessions" — particularly useful when a batch operation processes files incorrectly and the correct response is to restore and try a different approach rather than manually correcting 40 files. Official docs reference added.

A.concept.agents.md — the Subagents section expanded from two explanatory sentences to a full practical pattern: deliberately asking Claude to run investigation tasks (web research, reading a large document set) as subagents to preserve the main session context. The rationale is the context window as the primary performance constraint: exploratory work that fills context early forces a premature /compact or session restart; offloading it to a subagent keeps the main working space clean. Includes a concrete prompt example. Official docs reference added.

B.lifecycle.0.iteration.md — a new paragraph added to the "Fail quickly" subsection, immediately after the "Rapid early synthesis" bullet. The verify-your-work principle from the official best practices is integrated as the task-level instantiation of "fail quickly": including a verification checkpoint in the task description itself (process the first 3 files and show me a sample row before continuing; flag files with zero extractions) is named as "the single highest-leverage addition to any AI-assisted task." Framed explicitly as "the practical form of the 'fail quickly' principle at the individual task level" — connecting the official best practice to the document's conceptual argument rather than inserting it as a standalone tip.

D.tutorial.firstproject.md — official documentation link added to Related.

Conceptual trajectory of session 10

Session 10 is a consolidation session. No new documents were added; no new conceptual territory was opened. The work is of two kinds: correcting an outdated fact (the installation path) before it reaches participants, and improving the technical precision of existing content by grounding it in the official source. The best-practices additions are targeted rather than comprehensive — five documents received additions, each chosen because the relevant concept (four-phase workflow, checkpoint recovery, context window management via subagents, verification-in-task-description) was either absent from the project or mentioned only in passing. The result is that the A5, A9, A.concept.agents, and A.issue.plan-mode documents now carry both the conceptual treatment the project developed and the official operational guidance that the documentation provides — giving researchers two complementary framings of the same practice.

Session 11 — 2026-03-17

An eleventh working session (continuing the same day as session 10) refined the workshop-facing materials on four fronts: adding external resource references, correcting and expanding the three-tier tool comparison, clarifying Windows terminal requirements, and restructuring Block 1 of the workshop agenda to include a dedicated conceptual basics segment.

External resource references

D.tutorial.setup.md, D.tutorial.firstproject.md, A3.code-basics-non-programmers.md, d.plan.md — reference to the Claude Code in Action — Anthropic Academy free video course added to each. Placed in the "what to do next" or Related positions appropriate to each document's audience moment: setup tutorial (after installation), first project tutorial (in "What to do next"), basics doc (before Related), workshop plan (in the closing section for participants to take away).

D.tutorial.setup.md — a "Before you install" section added at the very top of the installation steps. This section explains that the Claude Desktop app already has Cowork and Code tabs built in (no installation required), and that participants with Pro subscriptions may already have agentic Claude access. Includes the Navigating the Claude Desktop App — Anthropic tutorial reference. Explains why the terminal installation is still needed for the workshop (git cloning, terminal visibility) while being honest that the Desktop Code tab covers most post-workshop research needs.

A1.desktop-vs-code.md corrections and expansions

A fetch of the official Claude Desktop documentation (code.claude.com/docs/en/desktop) produced several corrections and additions to A1.desktop-vs-code.md:

Desktop Code tab added as a distinct access path. The document previously presented Claude Code as terminal-only. The Code tab in the Desktop app — running the same Claude Code underneath, sharing CLAUDE.md files, hooks, skills, and settings — was added as a parallel path. The "Terminal required" and "Setup effort" table rows updated accordingly.

CLAUDE.md and skills confirmed shared. An earlier version of the document (added mid-session-10) incorrectly stated that the Desktop Code tab lacked CLAUDE.md and custom skills. The official documentation explicitly confirms: "CLAUDE.md files in your project are used by both / Hooks and skills defined in settings apply to both." The incorrect claim was removed; the correct statement added.

Cowork execution environment clarified. The table previously described Cowork's execution environment as "hidden Linux VM." Updated to "contained environment" following the official language. A note added that Cowork requires Apple Silicon (M1 or later) on macOS — unavailable on Intel Macs — which explains the containment model. A practical note for researchers: Cowork's contained environment may or may not bundle Python; test before relying on specific packages.

Code tab Python environment clarified. Both the Desktop Code tab and terminal Claude Code use system Python — Python must be installed on the machine; neither bundles it. Added to both A1.desktop-vs-code.md and D.tutorial.setup.md.

Terminal clarification in D.tutorial.setup.md

The tutorial previously instructed participants to open PowerShell without explaining why, implying it was the only option. The revised Step 0 explains that Windows has two terminals (Command Prompt and PowerShell), that most steps work in either, and that only Step 2 (the irm ... | iex install command) requires PowerShell because of PowerShell-specific syntax. Step 2 was restructured to present two equal options: winget install Anthropic.ClaudeCode (works in any terminal, no auto-update) and irm https://claude.ai/install.ps1 | iex (PowerShell only, auto-updates). d.plan.md Block 2 updated to match.

Windows Terminal added as optional Step 4. Microsoft's Windows Terminal (tabs, multiple shell profiles, modern design) added as an optional install — winget install Microsoft.WindowsTerminal — before Obsidian. Added to the checklist as an optional item. Obsidian renumbered to Step 5.

Block 1 restructure: conceptual basics added

d.plan.md Block 1 restructured from 40 to 45 minutes by inserting a 12-minute "Conceptual basics" segment between the three-tiers demo and the magic moments. The segment covers four items at ~3 minutes each:

1. How Claude works with your files — the folder-as-workspace shift; no uploading
2. Markdown as the bridge — PDF → .md conversion as the enabling layer for everything in the demos
3. Project memory: CLAUDE.md — why Demo 2 works and would fail in a cold Desktop session; the "briefing document every morning" analogy
4. Adoption spectrum self-placement — moved here from its previous position as a standalone closing item; works better as the frame for the demos than as a postscript

The magic moments section trimmed from 20 to 18 minutes (each demo remains individually timed; the introductory sentence changed to "The concepts are in place — let the demos land" as a presenter cue to resist over-explaining). The standalone adoption spectrum section at the end of Block 1 was removed, its content now fully absorbed into the conceptual basics segment.

Conceptual trajectory of session 11

Session 11 completes the workshop materials' transition from "what Claude can do" to "what participants need to know before they see it." The conceptual basics addition is the most structurally significant change: it solves a sequencing problem that the original Block 1 had — the magic demos required understanding markdown conversion, project memory, and the adoption spectrum to land properly, but the original structure put the adoption spectrum after the demos and addressed markdown and CLAUDE.md only implicitly. The revised Block 1 now follows a logical pedagogy: orient (scene setting) → compare (three tiers) → equip conceptually (basics) → demonstrate (magic moments). Each demo now has its conceptual prerequisite already in place, which changes the demos from "impressive things Claude can do" to "here is Level 2 in action." The external resource additions (Anthropic Academy, Desktop app tutorial) fill out the "what to do after the workshop" layer that was previously limited to the C-documents alone.

Session 12 — 2026-03-17

A twelfth session (continuing the same day as session 11) expanded the GitHub Pages site in three directions — making the concept index navigable, promoting the meta-documents to graph nodes, and adding a home panel — then wrote five new C-level synthesis documents, completing the project's practical reference layer.

GitHub Pages: concept index as browsable page

docs/_index.html (generated) — The _index.md concept index was made into a clickable HTML page. Prior to this session, _index.md existed only as a flat markdown file; its [label](file.html) links were never rendered as hyperlinks in any browsable context. The build script (build/build.py) received a dedicated post-Pass-2 step that reads _index.md, rewrites .md link targets to .html, converts via the existing markdown library, and writes docs/_index.html using the same PAGE_TEMPLATE as the document pages. _index.md remains excluded from the network graph — it is a navigation tool, not a content document. An "Index" link button was added to the #map-header in docs/index.html, and a .index-link button style was added to docs/style.css.

GitHub Pages: meta-documents as graph nodes

start.md, _history.md, and _ownership.md were added to the network graph as a new "meta" category. Previously excluded via both SKIP_FILES and the not f.startswith("_") filter, they required two changes to build/build.py: removing them from SKIP_FILES, defining a META_FILES constant, and modifying the md_files filter to include meta files despite their _ prefix. Three new category rules were prepended to CATEGORY_RULES; "meta": "#9B59B6" (purple) was added to CATEGORY_COLORS; and 'meta': 'Meta — project history & structure' was added to CATEGORY_LABELS in docs/index.html's JavaScript with a corresponding purple legend dot. Graph distortion risk was assessed in advance: start.md and _history.md have no ## Related sections and generate zero edges; _ownership.md has three Related links (to B.ownership, B.experience, and _history). The three purple nodes appear as a small cluster at the graph periphery with no hub effect. Node count rose from 73 to 76.

GitHub Pages: home panel

A #home-panel element was added to docs/index.html as a sibling of #detail-panel in #content-area. The panel occupies the right 50% of the screen on wide displays (≥900px), is visible by default on load, hides when a graph node is clicked (replaced by the document panel), and restores when the document panel is closed or closed via its own ✕ button. On narrow screens it is hidden via display: none !important. The panel's content has three zones: a quote zone (a random entry from an embedded nine-quote array drawn from C.why.md, with a ↻ refresh button that picks a new quote without repeating the previous one); a navigation zone (five thematic card sections: Start here, Install & setup, What can I do?, Risks & limits, Project meta); and a footer link to _index.html. The JavaScript additions modify openDetail() to hide the home panel, closeDetail() to restore it, and the resize handler to synchronise visibility with isSplitMode().

Three UI refinements followed in the same session: (1) a "Why?" heading (#quote-why, 2rem bold blue) was added above the opening quote mark to give the quote zone context for a reader encountering it cold; (2) the navigation sections were converted to floating card boxes — #home-nav changed from flex-direction: column to flex-wrap: wrap, each .nav-section given flex: 1 1 42% with card styling (border, border-radius, padding, rgba background); (3) .nav-section-title was enlarged from 0.7rem uppercase muted text to 0.9rem full-weight white text, removing the uppercase treatment that made the headings feel like labels rather than section titles.

New C-level documents (five)

C.cheatsheet.md — Quick reference: Claude Code for researchers. A one-page scannable reference intended to be kept open in a browser tab or printed during the first weeks of use. Synthesises A5 (keyboard shortcuts), A5 (slash commands), A1 (tool decision matrix), A.issue.privacy-security (data type table), and workshop experience (when-stuck checklist). Five sections: keyboard shortcuts table, slash commands table, "which tool?" decision matrix, privacy quick-check table, and a five-point when-stuck protocol. Distinguished from all other C documents by its format: no explanatory prose, almost entirely tables and lists. Its brevity is the point — it is the residue of all the longer documents.

C.calibration.md — Calibration: what AI is actually good at for researchers. A balanced performance assessment for sceptical readers, structured around Pepinsky's execution/interpretation distinction introduced in A.critical.limitations.md and the B.lifecycle.4.dataanalysis.md document. Three primary sections: where AI demonstrably helps (seven areas including pattern recognition, first-draft generation, structured extraction, consistency across volume, multilingual access, dialogue); where performance drops (five areas including factual reliability, qualitative interpretation, original argument generation, literature search, self-knowledge about errors); and honest trade-offs (speed vs. depth, breadth vs. reliability, fluency vs. accuracy, delegation vs. atrophy). Closes with a symmetrical "signs you're using it well / signs you may be fooling yourself" section drawn from the epistemics and ownership B documents. This is the document that C.why's motivations need as a counterweight: where C.why lists reasons to try AI, C.calibration gives the performance limits within which those reasons hold.

C.ethics-compact.md — Ethics and integrity: three decisions. Condenses the ethical landscape — scattered across A.issue.privacy-security, E.muni-guidelines, E.journal-funder-policies, and B.ownership — into three concrete decision points every researcher faces before using AI on a piece of work. Decision 1 (Can I give this data to Claude?): reproduces the decision matrix from A.issue.privacy-security, adds the MUNI binding rule verbatim, and clarifies the GDPR dimension and the "local does not mean private" distinction for Claude Code. Decision 2 (Do I need to disclose?): extracts the universal disclosure rules, provides a per-funder/per-publisher summary table, and gives the safe-baseline disclosure wording from E.journal-funder-policies verbatim. Decision 3 (Am I still the intellectual author?): applies the five ownership dimensions from B.ownership as a practical table, states the "can you defend this in a seminar?" test, and provides the self-assessment prompt. Closes with a note on the compound decision — the interaction of all three — naming both the worst-case scenario and the clean-conscience scenario explicitly.

C.prompts.md — Prompt gallery: research tasks. Twenty copy-paste-and-adapt prompts for common humanities research tasks, organised into five sections: (1) reading and synthesis (four prompts: single paper critical reading, source comparison, lens-based reading, reading list triage); (2) corpus work (four prompts: folder triage, structured extraction with "not stated — do not infer" instruction, batch annotation with exact-quote requirement, cross-corpus connection finding); (3) writing support (four prompts: section drafting, targeted paragraph iteration with labelled alternatives, hostile-reviewer stress-test, clarity editing with before/after format); (4) project setup (three prompts: CLAUDE.md from conversation, reading log creation, extraction schema design); (5) DISSINET-specific (three prompts: Latin inquisition source analysis, person/relation network extraction with certainty column, place-in-project-context). Each prompt is accompanied by a "why this works" note explaining the phrasing — not for justification but to make the logic transferable. The "not stated — do not infer" instruction in corpus extraction and the "do not soften the critique" in stress-testing are called out as specifically load-bearing.

C.workflows.md — End-to-end workflows. Four complete step-by-step workflow descriptions for common research tasks, each covering the full arc from empty folder to finished output: (1) reading a set of papers (convert → triage → deep read → synthesise → update CLAUDE.md; 5 steps); (2) writing a grant section (orient → draft → self-review before asking for revision → targeted iteration → stress-test; 5 steps); (3) processing an archival corpus (triage readability → convert → extract structured data → find patterns → close read priorities; 5 steps); (4) setting up a new project (create folder → dialogue about project → CLAUDE.md draft → folder structure → start.md → first test task; 6 steps). Each workflow embeds prompts from C.prompts, specifies folder structure prerequisites where relevant, and closes with "what success looks like" — a concrete description of the output state that distinguishes done from merely in-progress. Workflow 4 closes by identifying its completion moment as the Level 2 transition on the adoption spectrum.

Conceptual trajectory of session 12

Session 12 completes two open threads simultaneously. The GitHub Pages additions close the gap between the project's documentary completeness and its navigability: the graph was already a strong entry point for readers who knew what they were looking for, but the concept index (now clickable as _index.html), the meta-documents (now navigable as purple nodes), and the home panel (now the default landing state) together constitute a proper entry layer for readers who do not. A researcher arriving at the site cold can now read the quote, follow a thematic navigation link, discover the concept index, and reach any document without having to identify a node in the graph first. The five C-documents complete the project's practical reference layer. The existing C documents (C.why, C.tasks, C.dangers, C.leveling-packages) established the motivational, taxonomic, risk, and transition dimensions of the project's synthesis. The new five add the operational and calibration dimensions: how to prompt, how to work end-to-end, what honest performance looks like, how to handle the ethics, and where to find everything in one page. Together the nine C documents now cover the full range from "should I bother?" to "here is what to type."

Session 13 — 2026-03-17

A thirteenth session (continuing the same day) was a maintenance and integration session: a browser demonstration task, a skill installation, and the absorption of pre-gathered external references into three existing documents.

Browser research: religionistika.phil.muni.cz

The browse skill was used to navigate to the homepage of the Department of Religious Studies (Ústav religionistiky) at Masaryk University's Faculty of Arts. A full-page screenshot was taken and saved to the project directory as religionistika.png. The exercise also documented a WSL2 platform finding: Ctrl+V image paste does not work in Windows Terminal under WSL2 due to binary clipboard limitations; the recommended alternatives are file-path references and Claude Desktop for Windows.

Skill installation: frontend-design

The frontend-design skill from anthropics/claude-code was installed locally via npx skills add anthropics/claude-code --skill frontend-design --yes, creating .agents/skills/frontend-design with a symlink to Claude Code. Installed project-locally (not globally); noted that --global would be required for cross-project availability.

Integration of _sources/scientific.skills.md

The user had pre-gathered a source notes file (_sources/scientific.skills.md) containing eight references — GitHub repositories, Reddit threads, a Medium practitioner article, a Google DeepMind research blog post, and an arXiv paper — relevant to Claude skills for scientific and academic work. Claude digested the file and distributed the references into three existing documents:

A.skills-ecosystem.md — Discovery channels expanded. Two new entries added to the discovery channels list: the r/ClaudeAI community thread on best skills for writing, research, and productivity; and the Medium article "10 Must-Have Skills for Claude (and Any Coding Agent) in 2026." The alirezarezvani/claude-skills entry was also corrected from "177 skills" to "192+" to match the source's stated figure.

A11.examples-claude-code-researchers.md — two new sections. "Large-scale academic research with multi-agent Claude Code" documents the Agents Research Lab Reddit thread as a practitioner account of orchestrating multiple agents across a literature corpus — one of the more detailed public accounts of multi-agent Claude Code applied to genuine research tasks rather than demonstrations. "AI as research collaborator: the co-scientist paradigm" documents Google DeepMind's AI co-scientist blog post and arXiv paper 2502.18864 as a conceptual anchor for the AI-as-research-partner framing, with an explicit connection to the Socratic partner claim in B.lifecycle.1.creativity and the execution/interpretation distinction in A.critical.limitations.

A.adjacent.tools.md — oh-my-openagent added. The open-source agent harness oh-my-openagent (previously oh-my-opencode) added to the broader landscape section: a layer on top of coding agents (Claude Code, Codex, Gemini CLI) for shared configuration, skills, and team workflows. Positioned as relevant to teams running Claude Code at scale, not to individual researchers starting out.

Conceptual trajectory of session 13

Session 13 adds no new documents and makes no structural changes. Its intellectual contribution is the absorption of external references that confirm or extend frameworks the project had already established. The most conceptually significant addition is the AI co-scientist material: it introduces a named paradigm — distinct from the vague notion of "AI assistance" — that sits precisely at the intersection of B.lifecycle.1.creativity's Socratic partner claim and the larger question of what AI-assisted research can mean at the frontier. The execution/interpretation distinction, already central to A.critical.limitations and B.lifecycle.4.dataanalysis, now has an explicit external exemplar: the DeepMind co-scientist paper makes the same point, which means the workshop can cite the framework as confirmed by independent work rather than merely asserted. The session also illustrates in practice the _sources/ pattern of pre-gathering references before integration — separating the research act from the synthesis act, consistent with the iteration principle in B.lifecycle.0.iteration.

Session 14 — 2026-03-17

A fourteenth session (same day, short) surfaced and fixed a silent installation failure in the markitdown toolchain — the kind of friction that would stop workshop participants in their tracks — and converted the AI co-scientist paper to markdown as source material.

PDF conversion: Towards an AI co-scientist

The user asked Claude to convert _sources/Gottweis et al._2025_Towards an AI co-scientist.pdf to markdown using markitdown. The conversion exposed an installation gap: pip install markitdown (the command documented in A.markdown-central.md) installs the package successfully but without PDF support. The PDF converter is an optional dependency group requiring pip install "markitdown[pdf]". Running the bare install produces no warning; attempting to convert a PDF then throws a FileConversionException citing MissingDependencyException. After installing markitdown[pdf], the conversion completed successfully: 4,846-line markdown file saved to _sources/Gottweis et al._2025_Towards an AI co-scientist.md.

Documentation fix: markitdown[pdf] — two documents

The discovery was immediately applied to the workshop documentation:

A.markdown-central.md — the primary installation instructions (pip and uv variants) were both corrected from markitdown to "markitdown[pdf]". A blockquote warning was added explicitly naming the failure mode: the bare install succeeds and the tool runs, but PDF conversion silently fails. This is a particularly dangerous failure because there is no visible error at install time — participants would only discover the problem when attempting to use the tool for its primary purpose.

A.setup.windows-wsl.md — two fixes: the WSL Step 5 install command (uv pip install) was updated to include [pdf]; the Windows-native troubleshooting note for markitdown was rewritten to lead with the correct install command and explain the silent-failure pattern rather than pointing only to Administrator permissions.

Conceptual trajectory of session 14

Session 14 is a single corrective action of high practical importance. The markitdown [pdf] issue is a textbook workshop failure point: the tool is installed (no error), it appears ready, and it fails only when participants try to use it for the task they installed it for — with an error message that requires understanding optional Python dependency groups to interpret. Left unfixed, this would break the PDF-to-markdown workflow at the worst possible moment in a live workshop. The fix required encountering the problem by doing the actual work (converting a real PDF), not by reading documentation. This is also a small argument for why _sources/ material — actual papers and PDFs — should be exercised during project development rather than deferred to the workshop itself: real use surfaces real gaps.

Session 15 — 2026-03-17

A fifteenth session (continuing the same day as session 14) enriched the knowledge base visually, created a Remotion video summarising the project's development history, completed the /update-index maintenance task, and rebuilt the GitHub Pages site with new diagram assets.

Visual enrichment: Excalidraw diagrams for four documents

Four Excalidraw diagrams were designed, rendered to PNG, and embedded in their respective source documents — following the precedent of research-lifecycle.excalidraw from session 4.

Selection rationale: The four documents chosen contain inherently spatial or structural models that prose struggles to convey: a cycle (the agent loop), a spectrum (the adoption ladder), parallel flows (data paths by tool), and a concentric map (center/periphery). A plan-mode evaluation of the full document set informed the selection; B.epistemics.md and A1.desktop-vs-code.md were consciously skipped — the causal chain in the former works adequately in prose; the latter already has a comparison table.

Diagram assets created:

• agents-diagram.excalidraw / docs/assets/agents-diagram.png — two-panel layout: left panel shows the agent cycle (Perceive → Think → Act, three purple rounded rectangles in a triangle with curved arrows and a "Claude" center label); right panel shows the three supervision modes (Supervised / Semi-supervised / Autonomous, stacked green/amber/red boxes with a "full control ↔ full autonomy" spectrum arrow). Embedded in A.concept.agents.md before the supervision modes table.

• adoption-spectrum-diagram.excalidraw / docs/assets/adoption-spectrum-diagram.png — a vertical 5-level ladder with colour progression (gray at L0 through solid blue at L2 to red at L4), a "key threshold" badge pointing to Level 2, and brief descriptor text below each box. Embedded in B.adoption-spectrum.md after the introductory paragraph.

• privacy-dataflow-diagram.excalidraw / docs/assets/privacy-dataflow-diagram.png — three parallel swim-lanes (Desktop in orange, Claude Code API in blue, Local/e-Infra in green), each showing the data flow from user through processing to response, with training annotations and GDPR notes. Embedded in A.issue.privacy-security.md after the "where does your data go?" orienting sentence.

• centroid-periphery-diagram.excalidraw / docs/assets/centroid-periphery-diagram.png — a concentric spatial map: a solid inner ellipse (center zone, blue fill, "AI excels here") overlaid on a larger outer ellipse with a dashed amber border (periphery zone, "AI misleads here"), with activity labels scattered into the appropriate zones. Embedded in B.centroid-periphery.md after the opening section.

Infrastructure additions: docs/assets/ directory created (managed by build/build.py, which received an os.makedirs call for this directory); docs/style.css gained image and figure styles (.doc-content img, .doc-content figure, .doc-content figcaption) so embedded diagrams render cleanly in document pages. Site rebuilt: 82 nodes, 384 links, 82 generated pages.

Render pipeline: Each .excalidraw JSON file was written to the repo root (matching the research-lifecycle.excalidraw convention), then rendered to docs/assets/ using the project-local excalidraw skill (uv run python render_excalidraw.py). Markdown image references use assets/name.png which resolves correctly from docs/foo.html pages without modification to the build link-rewriting regex.

Remotion video: project history animation

remotion-history/ — A Remotion React project created to produce a short animated video summarising the project's development history using _history.md as source material. Seven scenes in sequence: Title card, Origins (1 file, the pre-session seed), Phase A (45 documents), Phase B (18 documents), Phase C+E (7 documents), Phase D (the live site), and an End card ("7 sessions. 72 documents."). Technical structure: src/index.ts (the required registerRoot() entrypoint), src/Root.tsx (composition registry, 1920×1080, 30fps, 210 frames), src/ProjectHistory.tsx (7 scenes using <Series>, spring(), interpolate(), Easing). The Scene component uses fadeIn() and slideUp() helpers for consistent transitions; stat counters animate from 0 to target using Easing.out(Easing.exp). Two visual layouts: centered (title/end cards) and content (left-aligned with an animated vertical accent bar). Notable technical issue: initial launch failed with "No Remotion entrypoint was found" until an explicit src/index.ts file with registerRoot() was created and the package.json scripts were updated to reference it explicitly.

Index maintenance: .claudeignore entry

The /update-index task from the prior session was completed: a .claudeignore entry was added to the Privacy and security section of _index.md, characterising it as "a file placed in the project root listing files and folders Claude should never read; independent from .gitignore; protects credentials, raw personal data, and embargoed material in agentic sessions," linked to A.issue.privacy-security (primary) and A.setup.settings-local (secondary).

Conceptual trajectory of session 15

Session 15 is an investment in legibility rather than coverage: it adds no new intellectual content but makes existing content substantially more accessible. The four diagrams each address the same pedagogic problem — models that are spatially intuitive resist prose compression — and the selection was deliberate rather than exhaustive. The agent loop's circular dynamic, the adoption spectrum's step-wise accumulation, the data privacy paths' parallel divergence, and the center/periphery model's concentric structure are all diagrams that a careful reader could eventually draw from the text, but would grasp in under a second from the image. The Remotion video represents a different kind of legibility investment: it makes the project's own development history narratable as a two-minute artifact rather than readable only as a log file. Both additions are consistent with the project's self-demonstrating character — a project that teaches about AI-assisted research using exactly the tools AI-assisted research can produce.

Session 16 — 2026-03-17

A sixteenth session (continuing the same day) focused entirely on the GitHub Pages site's public face: making the homepage more inviting, expanding the concept spotlight, rewriting the motivational quotes, and replacing the diagram thumbnail grid with a readable auto-rotating carousel.

Homepage: diagram section promoted and redesigned

The four Excalidraw diagram PNGs created in session 15 were promoted to the home panel as a dedicated section. The implementation went through three iterations in one session.

First iteration: 2×2 thumbnail grid. Four cards in a two-column grid, each with a 78 px-tall image area (object-fit: contain, light #eef1f7 background) and a caption below. Label: "Visual guides." The cards were too small to read at any useful scale.

Second iteration: "Diagrams" label + visual refinement. The section label was changed to the neutral "Diagrams"; the card design gained a vertical flex-column structure, hover lift (translateY(-2px) + box-shadow), and a darker caption band.

Third iteration: carousel. Both prior iterations were abandoned in favour of a single-image auto-rotating carousel. The .diagram-carousel container holds a .diagram-slides track (four .diagram-slide flex children, each min-width: 100%) with CSS transform: translateX driven by JavaScript. A dot-indicator row shows position; clicking any dot jumps to that slide. Auto-advance fires every 4 seconds; mouseenter / mouseleave pause and resume rotation. Image height increased to 120 px. The timer is managed through a resetTimer() function (timer declared let, not const) so pause-on-hover works correctly by clearing and recreating the interval on mouseleave.

Homepage: split-screen navigation from home-panel links

Before this session, clicking any link in the home panel navigated the full page rather than opening the document in the split-screen detail panel. A delegated click handler was added to #home-panel after the network data fetch: it builds a slugToNode map from data.nodes, then intercepts clicks on a[href$=".html"], looks up the corresponding node, and calls openDetail(node). Links to non-node pages (e.g. _index.html) fall through normally.

Homepage: auto-incrementing version number

A persistent version indicator was added to the map header and to all generated document pages. build/build.py gained a get_version() function that calls git rev-list --count HEAD and git rev-parse --short HEAD, writes docs/version.json at build time, and injects {version} into the PAGE_TEMPLATE footer. The JS in index.html fetches version.json on load and populates a #site-version span in the map header. The version string format is v1.{commit_count} — auto-increments with every commit followed by a rebuild, with no manual version management required. The document footer gained a flexbox layout (space-between) so the version string sits right-aligned beside the "← Back to map" link.

Homepage: "Back to map" iframe fix

After the nav-back class was added to both the top nav link and the footer link in the document page template, the detail iframe onload handler was still only intercepting the first match — querySelector('.nav-back') returns one element. The fix changed the call to querySelectorAll('.nav-back').forEach(...), attaching the closeDetail() listener to both links.

Homepage: CONCEPTS array expanded to 28

The concept spotlight widget was expanded from 12 to 28 entries. Sixteen new concepts were selected by scanning 14 documents across the B and C clusters for coined terms and memorable framings: "The invisible transition" and "The mode-switch rule" (B.centroid-periphery), "Epistemic capture," "Atrophied judgment," and "Peer substitution" (B.autonomy), "The confirmation loop" and "Cross-model checking" (B.epistemics), "The pre-mortem" (B.lifecycle.0.iteration), "Verification checkpoints" (B.trust), "The Socratic partner" (B.lifecycle.1.creativity), "Plan mode" (A.issue.plan-mode), "The key conceptual jump" (B.adoption-spectrum), "Decomposition" (A.issue.bounding), "Literature finding fragility" and "The detectability spectrum" (C.dangers), "The third-party problem" (B.team-ai). All new concepts link to their primary document; original concepts link to C.philosophy-experience.

Homepage: WHY_QUOTES rewritten as standalone

The WHY_QUOTES array originally contained phrases extracted from C.why that were designed to be read inside their document — they read as fragments out of context. All twelve were replaced with standalone sentences stating a complete, surprising, or memorable claim without requiring the reader to know the source document. The revision principle: each quote should make sense to someone who has never opened any of the workshop materials.

Conceptual trajectory of session 16

Session 16 is the first session exclusively devoted to the public experience of the site — not its content, not its data, but how it presents itself to a first-time visitor. The carousel replaces four unreadable thumbnails with one legible image at a time: a small design decision that illustrates the readability-at-small-sizes problem the diagrams themselves are meant to solve. The concept spotlight expansion and quote rewrite share the same logic: the homepage should function as a conceptual invitation, not a document index. A visitor who sees "Atrophied judgment" in the concept slot or reads "The most dangerous AI risk is the one that feels like productivity" in the quote should want to know what that means — and find the answer one click away. The auto-version provides something subtler: a visible marker that this is a living project, not a static archive. Taken together, the session moves the site from functional to intentional.