skynet/claude-foundations
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add session log and reflect: API design research session

Browse Source 
Session log for 2026-03-29 covering API/LLM security research, agent-runtimes
audit, and review skill creation. Reflected into:
- decisions.md: best-practices topic split, review skills read-only design
- process-lessons.md: background agents for research, Edit context
  disambiguation, best-practices repo location

Pruned 2 old reflected logs (2026-03-17, 2026-03-18).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Paul O'Reilly
2026-03-29 11:22:37 +13:00
parent 884b416d38
commit 52b0f2b5c6
6 changed files with 56 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
memory/decisions.md
View File

@@ -68,6 +68,18 @@ Topic files at `~/.claude/status/<session-id>/claude-topic.txt`. Session ID uniq
Claude has no direct access to its own session ID. The status line script writes it to `/tmp/claude-session-id-<md5 of cwd>`, which `set-topic.sh` reads to find the correct per-session topic directory.
## Status line: Pending-topic queue for bootstrap race condition
`set-topic.sh` is called on the first message, before `statusline.sh` has written the session ID file. Instead of erroring, it writes to `/tmp/claude-pending-topic-<hash>`. `statusline.sh` picks this up on its next run via `mv` (atomic, no double-application). Simple and self-healing — statusline already runs after every response.
## Status line: Config must exist in every profile settings file
Each profile (`~/.claude`, `~/.claude-octopus`, `~/.claude-oreillyit`) has its own `settings.json` with no inheritance. The `statusLine` entry must be added to each independently.
Each profile (`~/.claude`, `~/.claude-octopus`, `~/.claude-oreillyit`) has its own `settings.json` with no inheritance. The `statusLine` entry and `Bash(~/.claude/status/set-topic.sh:*)` permission must be added to each independently.
## Best practices: One file per topic, not combined mega-documents
api-design.md and llm-code-security.md are separate files despite both being "security-adjacent". API design covers versioning, pagination, idempotency — not just security. Self-contained topic files are independently referenceable and can be loaded selectively by skills and agents.
## Review skills: Read-only output, not auto-edit
/review-plan and /review-spec are read-only (allowed-tools: Read, Glob, Grep). Review output informs the human rather than auto-editing plans/specs. This avoids unintended changes and reduces permission prompts. Both skills load all 5 design/security best practice files upfront — better to over-load context than miss a relevant check.