Pickup notes — 2026-07-13

TL;DR

1. Steps 1–10 of [[../Build-Order-Humain-VC-Unlock-Flow]] are DONE and the user has confirmed the deployed instance works end-to-end at https://augment.didi.sh (Railway, custom *.didi.sh domains). No prior pickup doc exists for this arc — the last one in context-v/reminders/ is Pickup-2026-06-03, over a month before any of the Railway deploy work happened.
2. This session was entirely bug-fixing + doc/credential hygiene, no new features. Four real fixes, all found by using the live app or by re-reading docs against the actual filesystem, not by anyone requesting new work.
3. Only Steps 11 and 12 remain open on the build-order plan. Step 11 (corpus backup to R2) needs one decision before it can be scoped: shared lossless-core bucket vs. a dedicated augment-it bucket — see “Open decisions” below.
4. No changelog entry has been written for any of this session’s work. Last changelog is 2026-07-09_01_.... Per git-conventions, this is worth doing before the next unrelated commit lands.
5. Working tree is clean on rebuild/turbo-rsbuild, pushed through fe6a203. Only dirty paths are submodule pointer bumps (clients/humain-vc, clients/reach-edu) that are deliberately left alone — per standing convention, the user tidies parent gitlinks manually after committing inside a child submodule, not the agent.

What shipped this session (chronological)

1. README app-structure audit (f8e4ab1). The “App structure” ASCII tree was missing 6 apps (affiliation-rating-resolver, person-db-resolver, person-enrichment, record-db-resolver, records-surface, strategy-curator) and 2 services (record-surrealdb-resolver, decile-mcp), and several listed ports were stale from before a port renumbering (record-collector was documented :3001, actually :3002; shell was documented :3000, actually :3100). Pulled every port fresh from each app’s rsbuild.config.ts rather than trusting the old doc. Also added narrative coverage for SurrealDB Cloud, didi.sh identity, the Flows registry (replacing the old single ROTATION), live multi-operator sync, and actor attribution.
2. GitHub Pages deploy was silently broken since 2026-07-08 (9ef8244). Root cause: that day’s “pin pnpm version” commit added packageManager: pnpm@10.15.0 to root package.json (for Railway’s Docker builds), which collided with .github/workflows/pages.yml’s hardcoded pnpm/action-setup@v4 version: 9 — “Multiple versions of pnpm specified.” Six pushes in a row never actually redeployed the splash; GitHub Pages was quietly serving a 2026-07-08 build the whole time. Fixed by dropping the hardcoded version so action-setup reads packageManager instead. Verified live: workflow ran green, https://lossless-group.github.io/augment-it/ is serving current content. Also resynced splash/pnpm-lock.yaml to what splash/package.json already declared (it had drifted to old astro 6.3.1/astro-pagefind 1.8.6). Also added a new feature-highlight card, “Build the corpus together, live” — the one shipped capability (NATS multi-operator sync) with no marketing coverage yet.
3. JINA_API_KEY / JINA_AI_API_KEY naming mismatch fixed (7891b15). docker-compose.yml and services/content-ingest/src/jina.ts have always read JINA_API_KEY; .env.example (and every local .env copied from it) defined JINA_AI_API_KEY. Degraded gracefully to Jina’s free/no-auth tier, so nothing looked broken, but content-ingest — including the deployed humain-vc instance — has been running on free-tier rate limits since day one. scripts/jina-fetch-urls.mjs already had a comment documenting this exact mismatch as a deliberate workaround; standardized on JINA_API_KEY everywhere instead of routing around it. User set JINA_API_KEY on Railway’s content-ingest service directly; it auto-redeployed to SUCCESS.
4. R2/JuiceFS credentials documented in .env.example (fe6a203). Discovered R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY, CLOUDFLARE_R2_API_ENDPOINT, CLOUDFLARE_ACCOUNT_ID, and JUICEFS_LOSSLESS_TOKEN already sitting in local .env, undocumented in .env.example — leftover from [[../../explorations/JuiceFS-Pinned-Path-Off-Local-Substrate]] (a 2026-06-18 exploration that ended deferred, never adopted into any live flow). That exploration’s own text says to remove the .env copy and keep ~/.secrets as the only canonical location — that cleanup never happened. User’s call: keep the redundancy deliberately (a solo dev’s ~/.secrets convention isn’t discoverable to a future contributor working inside augment-it/, and agent harnesses like Claude Code only get automatic filesystem access within a project’s own working tree, not a laptop-wide dotfile outside it). Added a comment block in both .env and .env.example documenting the redundancy and flagging the rotation-drift risk explicitly (same failure shape as item 3 above — two copies of a secret silently diverge when one gets rotated and the other doesn’t).
5. Two stale task-list entries corrected. Tasks #9 (“Domains: shell + workspace-service on *.didi.sh…”) and #10 (“Deploy all services and verify end-to-end”) were still showing pending/in_progress despite being done and user-confirmed working — marked completed.

Build-order plan status

Full detail, gotchas, and the DO→Railway pivot story: [[../Build-Order-Humain-VC-Unlock-Flow]].

Open decisions (need a human call before proceeding)

1. Step 11 bucket scoping. Corpus backup mechanism needs to be rclone (or similar S3-capable tool) syncing the Railway Volume to R2 — Syncthing was considered and ruled out for the backup leg specifically (it only syncs between two Syncthing daemons, no native S3/R2 support). Still open: does the backup destination reuse the existing tree-wide lossless-core bucket (simplest, but re-opens the per-client-isolation question that [[../../explorations/JuiceFS-Pinned-Path-Off-Local-Substrate]] deliberately left unresolved), or does augment-it get its own dedicated bucket + scoped API token? This blocks writing the actual rclone job.
2. Syncthing for laptop↔hosted live sync (separate from the R2 backup leg) — still an open “do we actually want this” question. Current single-writer policy is “sync deliberately, never concurrently,” which fits a one-shot pull/push better than a continuous P2P daemon. Running Syncthing on Railway would also require it as a second process inside the content-ingest container itself, since Railway volumes are single-service-only — a separate Syncthing service can’t mount the same volume.
3. DigitalOcean droplet (167.172.42.247) decommission — unused since the Railway migration, not yet decided.
4. Changelog entry for this session — not yet written, not yet explicitly requested by the user.

What to start with next session

Ranked by what unblocks the most:

1. Resolve the Step 11 bucket-scoping decision (open decision #1 above) — a 2-minute conversation that unblocks writing the actual rclone-to-R2 job.
2. Step 12 dress rehearsal — needs Aneil’s membership seeded on prod (this may already be done; verify), then two people signed in simultaneously on augment.didi.sh running real email sign-in, thesis creation, cross-screen liveness check, didi triage, and an attribution spot-check (frontmatter shows who did what). This is the actual acceptance test for the whole build-order arc.
3. Write the missing changelog entry for this session’s four fixes — quick, and keeps the splash’s “Recent” section (which reads straight from changelog/) from going stale.

Branch + git state

• Current branch: rebuild/turbo-rsbuild
• Last pushed commit: fe6a203 (doc(.env.example): document R2/JuiceFS creds + why they're duplicated on purpose)
• Working tree: clean except submodule pointer bumps in clients/humain-vc and clients/reach-edu — leave those alone, the user tidies parent gitlinks deliberately.
• Origin: in sync through fe6a203.

Critical files / where things live

• Active plan: context-v/plans/Build-Order-Humain-VC-Unlock-Flow.md — Steps 1–10 marked done in place, Step 11 flagged NEEDS REVISITING.
• Deployment reference: DEPLOYMENT.md (repo root) — live URLs, 8-service Railway table, env vars, redeploy commands, gotchas, “Known gaps” (now just corpus sync — the Jina entry was removed this session).
• JuiceFS/R2 background: context-v/explorations/JuiceFS-Pinned-Path-Off-Local-Substrate.md — read before touching Step 11’s bucket question.
• Splash deploy workflow: .github/workflows/pages.yml.
• Feature cards (splash marketing): splash/src/content/feature-highlights/*.md — hand-curated, not auto-generated from anything.
• Credential files: .env (local, untracked, has the R2/JuiceFS redundancy comment now) and .env.example (tracked, same comment, placeholder values).

Verify state on next session

git fetch --all --prune
git status                          # should be clean except clients/* submodule pointers
git log --oneline -5                # HEAD should be fe6a203
railway status --json | head -5     # confirm still linked to the right Railway project
curl -s https://augment.didi.sh/    # confirm the humain-vc instance is still live
gh run list --workflow=pages.yml --limit 1   # confirm splash deploy is still green

Related

• [[../Build-Order-Humain-VC-Unlock-Flow]] — the active plan this pickup reports against
• [[../../explorations/JuiceFS-Pinned-Path-Off-Local-Substrate]] — background for Step 11’s bucket-scoping decision
• DEPLOYMENT.md (repo root) — the deployment reference this session kept current
• [[../../reminders/Pickup-2026-06-03]] — the last pickup doc before this one (over a month prior; predates the entire Railway deploy arc)