Daily Log — 2026-04-12

Summary

Heavy focus on Crescent's card app platform infrastructure — implementing platform core, designing app vendoring/tarball strategy, and building foundational DOM components for the card + library ecosystem. Multiple delegated subagents completed critical app implementations. Four projects active: Crescent (primary), fuwafuwa (autonomous maintenance), io (metadata/naming cleanup), NixOS (Tailscale reversion).

Projects Active

• Crescent (7 conversations) — Platform design, CCv2 card format, app architecture, vendor strategy
• fuwafuwa (6 autonomous sessions) — Discord/moltbook monitoring, passive engagement
• io (2 messages) — Metadata/tags searching, reference cleanup
• NixOS (1 message) — Configuration restoration

Key Work: Crescent

Platform & App Architecture

Early morning recovery from network failure (06:49) — large continuation with ~51k output tokens. Pushed through several design questions around app vendoring, tarball structure, and capability-based security.

Vendoring strategy settled:

• First-party apps (card, library, adapters) vendor ALL dependencies (base64, json, reactive, lib.* modules) into their tarballs for portability
• Apps distributed as self-contained units — no external library dependencies required
• Users with "full" Crescent distribution can optionally use system libraries; first-party suite always bundles to prevent silent breakage
• Security implication: shipping source code in PNGs is acceptable because capability grants are explicit (platform validates required caps before running)

Convention clarified: Vendored deps live under _vendored/ inside app tarball root (first-party convention, not mandatory for third-party).

Library Modules Built

Three delegated subagents completed library implementations:

1. CCv2 Card Parser (ab9ee5e8 agent)

• lib/formats/ccv2/card.lua — Complete CCv2 card read/write (80 assertions)
• PNG tEXt "chara" chunk support (base64-encoded JSON v2, with v1 auto-wrapping)
• Plain JSON import/export
• Normalize function for defaults

2. CCv2 Adapter Apps (ac9938f2 agent)

• lib/formats/ccv2/adapters/import.lua — from_png/from_json returning {card, lorebook?} (34 assertions)
• lib/formats/ccv2/adapters/export.lua — to_png/to_json with lorebook attachment (38 assertions)
• Full round-trip compatibility tests (import → export → import)

3. Card App DOM (a6d20833 agent)

• lib/apps/card/manifest.json + lib/apps/card/dom.lua (82 assertions)
• Reactive state: messages, input, loading, current card, session ID
• Full send flow: LLM call → response append → error handling
• Context assembly: system prompt + history + optional greeting
• Widget layer: message list, loading indicator, input row, full app layout
• Init entrypoint: loads card from PNG, shows greeting, mounts to document.body

4. Library Browser App (a7cb6e15 agent)

• lib/apps/library/manifest.json + adapter + dom (71 assertions)
• Two adapter backends: static (pre-loaded array) and composite (multiple sources)
• Reactive filtering: case-insensitive substring match on metadata
• Toggle between grid/list view modes
• Widget: search input, mode toggle, item count, reactive item grid

Design Questions Explored

Tarball containment & platform boundaries:

• Apps are self-contained tarballs (not directly executable — require platform loading)
• No Lua symlinks or path manipulation — standard require() with tarball-relative root as namespace
• Host provides fallback lib.* modules if app doesn't vendor them
• Solved: where to put platform vs app-specific logic (platform infrastructure in host, app logic vendored)

Card format & type safety:

• Questioned whether to use full TypeScript-style typedefs vs untyped JSON
• Pragmatic approach: CCv2 format normalized with known structure, adapters provide interface boundaries
• Version detection: v1 (no spec field) vs v2 (structured spec)

Lorebook isolation & SQLite constraints:

• Initial trigger approach failed (qualified names recursion in temp views)
• Redesigned: structured write helpers + authorizer for DDL protection instead of triggers
• App must include app_id in INSERT/UPDATE/DELETE — security question: how to enforce this? (deferred to runtime validation in caps.db API)

Minor Issues & TODOs

• js_types.lua method convention mismatch — document field types remain any (TODO in codebase)
• Base64 encoding in PNG chunks — questioned for simplicity; settled as acceptable
• Settings view: fields not fully specified
• Shell design: needs dedicated design pass (library adapter API, facet composition rules, keyboard nav)
• Card UI: exact gesture thresholds, action menu layout

Projects: Auxiliary

fuwafuwa (Autonomous)

Six autonomous sessions tracking Discord + moltbook activity. Maintenance mode — monitoring conversations, keeping passive engagement, low throughput expected for freetime sessions.

io

Two quick messages:

• Searching sessions for "tags"/"metadata" mentions (preparation for broader metadata audit)
• Removing 'private-recipient-b' references from codebase using git filter

NixOS

Single message: restored Tailscale configuration (checking git history for previous setup).

Token Usage

Project	Conversations	Out Tokens	Cache Read	Cache Create	Avg Cache Hit %
crescent	5	~174,000	15.3M	378k	~97.5%
fuwafuwa	6	~28,400	3.6M	143k	~96.1%
io	2	~6,700	510k	44k	~92.1%
nixos	1	461	61k	6.7k	~90.0%
Total	14	~209k	~19.5M	571k	~97.1%

High cache efficiency across all projects. Crescent sessions show typical pattern: initial large continuation (51k tokens), followed by shorter design discussions with heavy context reuse.

Observations

1. Vendor-everything strategy works for closed ecosystems — Crescent is LuaJIT-based with minimal stdlib, making tarball self-containment tractable. PNG-bundled source code + capability grants creates interesting distribution/security tradeoff.

2. Subagent delegation effective for module implementations — Four parallel library builds with high assertion coverage (76+ assertions each), minimal back-and-forth required once spec was clear.

3. Design-first prevents rework — Early conversations around platform boundaries, app packaging, security model prevented mid-implementation pivots. The "structured write helpers" discussion (vs triggers) and vendor strategy both involved live rethinking but converged cleanly.

4. Crescent's scope is maturing — From "generalized SillyTavern alternative" to concrete three-app suite (card, library, adapters) with clear boundaries. First-party apps are reference implementations; third-party apps follow same pattern but less constrained.

5. Metadata/search emerging as ecosystem need — Both io and fuwafuwa showing interest in "tags" / "metadata" across projects. Likely prep for cross-project knowledge infrastructure.