Commits
Benchmarks for project/task management feasibility:
- Reactive invalidation: 241ns at 10k blocks, O(affected) not O(n)
- Critical path method (CPM): 9.6ms at 10k tasks via Steel scheduler
- SQLite recursive CTE for dependency queries: 7.7µs at 10k tasks
- Graph generator for synthetic DAG workloads
Results documented in evidence/30-pm-spike-results.md.
- §3.4 Op catalog: quick-reference table for all six ops (when it fires,
what it mutates, what it captures for undo) plus user-action → op mapping
- §5.1 Block composition reference: fields on every block, block variants
by rendering supertag, and the page-is-a-block model
- §14 Worked op log sequences: concrete JSONL examples for common user
actions (create page, tag #Task, convert to #Code, delete, collapse,
concurrent two-device edit with HLC merge)
Every LogOp carries an optional sig: Option<Ed25519Signature> field for
op-level authentication. Three escalating levels: local signing (Level 2),
RFC 3161 trusted timestamping (Level 2.5), atproto publishing (Level 3).
- New design doc: 31-authentication-and-evidence.md
- Spec 01: sig field on LogOp, op signing section
- Spec 02: .tsr sidecar for RFC 3161 timestamp tokens
- Spec 27: .tsr sidecar in checkpoint directory layout
- Design 06: PDS self-hosting caveat for evidence use cases
- ADR-021 added to decisions log
The sig field ships in format v1 as None by default; retrofitting signatures
onto existing ops is impossible, so the field must exist from day one.
The claim that Loro's shallow snapshots 'can't accept concurrent updates'
was false — Loro is a CRDT library and handles concurrent updates by design.
The actual finding: shallow snapshots can't import deltas that depend on
trimmed history, which is inherent to any compaction scheme including ours.
Corrected in: ADR-002, Spec 01 §1, Spec 21, Spec 22, Spec 27, evidence/26,
archive/14. ADR-002 now documents the Loro vs Path C+ decision as a strategic
tradeoff with a feature compatibility table.
- llm/: design docs, specs, evidence, openspec, and archive
- bench/: performance spike harnesses (oplog, yrs, loro, kleppmann fuzz)
- .gitignore: exclude .DS_Store, Rust target/, node_modules/
Benchmarks for project/task management feasibility:
- Reactive invalidation: 241ns at 10k blocks, O(affected) not O(n)
- Critical path method (CPM): 9.6ms at 10k tasks via Steel scheduler
- SQLite recursive CTE for dependency queries: 7.7µs at 10k tasks
- Graph generator for synthetic DAG workloads
Results documented in evidence/30-pm-spike-results.md.
- §3.4 Op catalog: quick-reference table for all six ops (when it fires,
what it mutates, what it captures for undo) plus user-action → op mapping
- §5.1 Block composition reference: fields on every block, block variants
by rendering supertag, and the page-is-a-block model
- §14 Worked op log sequences: concrete JSONL examples for common user
actions (create page, tag #Task, convert to #Code, delete, collapse,
concurrent two-device edit with HLC merge)
Every LogOp carries an optional sig: Option<Ed25519Signature> field for
op-level authentication. Three escalating levels: local signing (Level 2),
RFC 3161 trusted timestamping (Level 2.5), atproto publishing (Level 3).
- New design doc: 31-authentication-and-evidence.md
- Spec 01: sig field on LogOp, op signing section
- Spec 02: .tsr sidecar for RFC 3161 timestamp tokens
- Spec 27: .tsr sidecar in checkpoint directory layout
- Design 06: PDS self-hosting caveat for evidence use cases
- ADR-021 added to decisions log
The sig field ships in format v1 as None by default; retrofitting signatures
onto existing ops is impossible, so the field must exist from day one.
The claim that Loro's shallow snapshots 'can't accept concurrent updates'
was false — Loro is a CRDT library and handles concurrent updates by design.
The actual finding: shallow snapshots can't import deltas that depend on
trimmed history, which is inherent to any compaction scheme including ours.
Corrected in: ADR-002, Spec 01 §1, Spec 21, Spec 22, Spec 27, evidence/26,
archive/14. ADR-002 now documents the Loro vs Path C+ decision as a strategic
tradeoff with a feature compatibility table.