Project Laboratory System
The append-only record format, validation rules, generated WordPress views, corrections, and maintenance workflow.
Chronological record
Correct ambiguous project-page slugs discovered after the initial local import.
2026-10-23 · Contemporaneous implementation and verification date; exact command times were not retained publicly.
Evidence source
Guarded importer output, anonymous HTTP checks, and the payload link graph.
Verified starting state
- All seven pages were drafts, but two generic child URLs redirected anonymous visitors to older published pages with matching slugs.
- No live site or menu had been modified.
Actions recorded
- Assigned all six project pages explicit collision-resistant slugs ending in -history.
- Migrated the six managed drafts in place, preserving their WordPress IDs and parent relationship.
- Repeated importer verification and anonymous HTTP checks.
Results, failures, and uncertainty
The same seven managed WordPress IDs remain in place as drafts.
All seven intended laboratory routes now return 404 to logged-out visitors with no redirect to unrelated content.
The initial record's reference to the laboratory-system child slug is superseded by laboratory-system-history, and the other project pages follow the same -history convention.
Next action: Use the page_slug field for any future project whose data key should differ from its collision-resistant WordPress route.
- Guarded import and anonymous-route verification output · observed 2026-10-23
Record ID · 2026-10-23-project-laboratory-slug-correction
Create a living, append-only technical project-history system whose public pages are reproducible derivatives.
2026-10-23 · Contemporaneous implementation date; exact command timestamps were not retained in the public record.
Evidence source
The implemented validator, renderer, schema, guarded importer, and automated unit-test output.
Verified starting state
- The local site contained narrative project pages and conversation histories but no single structured, cross-project technical chronology.
- Existing project pages, galleries, and navigation had to remain unchanged.
Actions recorded
- Defined six project histories and a reusable JSON entry format.
- Implemented validation, safe public projection, deterministic page generation, scaffolding, append, and correction commands.
- Implemented a guarded importer that refuses nonlocal sites and forces all seven generated pages to draft status.
- Added tests for validation, safe rendering, correction preservation, sensitive-path rejection, and reverse-chronological presentation.
Results, failures, and uncertainty
The first chronology test failed because its string search matched a cross-reference to the correction before it matched the correction entry's article anchor.
The test was corrected to compare article anchors; all five unit tests then passed.
Two consecutive builds produced byte-identical WordPress payloads.
The host did not provide a PHP executable, so importer syntax validation was deferred to the WordPress container.
The first guarded importer dry run rejected a duplicate slug because the laboratory-system project initially reused the root index slug.
The subsystem page received the distinct child slug laboratory-system; the failed dry run made no WordPress changes.
Next action: Import the seven generated pages as local drafts, verify anonymous visibility and links, and preserve the maintenance workflow in the handoff.
- Project Laboratory generator and validator · SHA-256
a67860d0a6781d00c1093ce78f0c979346c6c0bc958061952074ea164085d516· observed 2026-10-23 - Project Laboratory unit tests · SHA-256
e06c998821bdb3d37fc4e5924fc476159edef65df3fffa54555c3424ff1951da· observed 2026-10-23 - Project log entry schema · SHA-256
6bcea566a44cc5ea64faa99f15df17b9f2883fe90798dcd124b7dd887fa22450· observed 2026-10-23
Record ID · 2026-10-23-project-laboratory-initial-build
