Robert Allan JamesandClaude Sonnet 5
1e2dc7fbf0
Ran the amd64 kernel acceptance leg 5 times back to back as the punch list's action item asked. dict_hash was byte-identical across every run for every VM (Artemis, both Hermes instances, Hera/MAMA_INIT), and matched aarch64/riscv64 exactly each time. Not jitter, and not stable-but-different either. The underlying mechanism the hypothesis pointed at is still real and unchanged (capsule_dict_hash_hook() still folds execution_heat into the hash; amd64 still runs its timer in RELATIVE mode under this hypervisor) — but PARITY:MAMA_INIT and the child-VM PARITY:BIRTH lines all print before the heartbeat starts, and heat only decays on heartbeat ticks, so there's no window for the timer's non-determinism to reach execution_heat before any of these hashes get computed. Most likely the original 2026-07-24 observation was a one-off (loaded host machine, coincidental timing), not a real gap. No code change. No amendment to CLAUDE.md's acceptance criteria needed — "identical dict_hash across all three architectures" holds up under repeated testing. Closure note added to the punch list; the 5 verification runs' logs and DoE CSVs are kept as the supporting evidence. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Session Logs
Historical development session summaries preserved for context and reference.
Purpose
These are informal notes from development sessions, documenting:
- Long debugging sessions with significant findings
- Experimental iterations and design decisions
- Development context and rationale
- Dead-ends and lessons learned
When to Create Session Logs
✅ Do create session logs for:
- Multi-hour debugging sessions with important discoveries
- Experimental work with multiple failed attempts before success
- Design discussions that made important architectural decisions
- Complex refactoring with non-obvious rationale
❌ Don't create session logs for:
- Routine development (use git commit messages instead)
- Formal documentation (use appropriate numbered directory)
- Final implementation details (use architecture docs)
Important Notes
⚠️ Session logs are archival and may contain outdated information
- Always consult current documentation first
- Information here reflects the state at the time of writing
- Design decisions may have been revised
- Code examples may be superseded
Contents
- 2025-11-20-recap.md - Development recap session
- 2025-11-26-worklog.md - Work log summary
- experimental-addendum.md - Experimental work notes
- experimental-iteration-usage.md - Iteration notes
- serialized-questing-pike.md - Design exploration notes
Relationship to Formal Documentation
Session logs supplement formal documentation but don't replace it:
| Session Logs | Formal Documentation |
|---|---|
| Informal notes | Structured guides |
| Point-in-time snapshots | Maintained and current |
| Developer perspective | User/maintainer perspective |
| Context and rationale | How-to and reference |
For Current Developers
If you're looking for information:
- Check formal docs first:
../01-getting-started/,../03-architecture/, etc. - Search session logs if you need historical context
- Update formal docs if you find valuable information only in session logs
For Historical Research
Session logs provide valuable insight into:
- Development process and methodology
- Design evolution over time
- Challenges faced and solutions developed
- Team decision-making rationale