Add Akashic Records KB page

Safely link my Obsidian vault to a new apocky.com KB page call it the Akashic Records, so people can read/view/peruse/analyze/observe my Medium.com works and other works.

I’m treating “link” as a governed publication bridge, not direct public access to the vault: only explicitly approved works should leave Obsidian, with provenance, redaction checks, and revocation. I’ll first inspect the existing apocky.com and knowledge seams, then implement the smallest reversible slice that fits the current architecture. I’m using `apocky-loop` for the boundary-crossing change, `critical-analysis` for the privacy/publication decisions, and `graphify` if this repo has an existing graph index.

The first state probe hit the known PowerShell pipeline parser edge; nothing was changed. I’m splitting the inspection into simpler read-only commands and continuing.

I’ve confirmed the governing boundary: local research/code is allowed, but a vault-wide public export is not. The safe design must be deny-by-default, publish only explicit allowlisted notes or already-public canonical URLs, preserve attribution and source dates, and support one-step withdrawal. I’m now checking three independent surfaces in parallel: the real website source, the local vault candidates, and the currently deployed site. No files or public content are being changed in this discovery pass.

Because this crosses three systems—Obsidian, Medium, and the production website—I’m also loading `apocky-wayfinder` to keep publication scope, dependencies, rollback, and the eventual cutover gate from collapsing into a single “page exists” checkbox. It keeps this discovery pass read-only and will make the handoff/restart point exact if your approval is needed before exposure.

The CSSLv3 graph exists, but its CLI is currently degraded (`uv` cannot canonicalize the trampoline path). Per the Graphify rules I’m preserving that as a failed observation and switching to its read-only query fallback; exact source remains the authority.

The fallback interpreter recorded in the graph is also gone, so the graph is doubly stale as an execution surface. I won’t retry that same route; I’m reading its JSON directly for orientation and will trust only exact website source afterward.

The source audit also confirms the active website repository is heavily dirty, so I will not place this work into that checkout or overwrite anyone’s changes. If the blueprint is approved, the implementation should start from a clean, deployment-matched worktree and stay isolated until its tests and visual review pass.

A live naming collision surfaced: apocky.com already has a public technical spec at `/docs/18_AKASHIC_RECORDS`. I’m preserving it and treating the new `/akashic-records` as the human-facing works archive, with explicit labels so readers and search engines do not confuse the two. The live CSP also rules out embedding or browser-fetching Medium, which reinforces the same-origin curated projection.

I’ve confirmed the safe boundary: this should be a curated publishing bridge, never a live mount of your vault. The last two audits are now resolving the exact vault and website seams so I can give you a concrete, reviewable blueprint without exposing note contents.

The public site already has an older technical document named “Akashic Records,” so I’m preserving that URL and treating the new page as “Akashic Records — Works by Shawn Apocky.” I’m also ruling out Medium embeds or live fetches: the current site security policy deliberately blocks them, which fits the safer static-publication design.

I resolved the safe design, but did not publish anything yet: the vault currently has no positive public allowlist. Key findings: - Primary source: [Obsidian Vault](<[redacted:local-path]/Documents/Obsidian Vault>). The phone-backup vault remains excluded. - The Medium mirror contains 230 posts: 204 apparently non-drafts and 26 explicit drafts, plus bookmarks, claps, profile and account data. “Non-draft” does not prove current publication approval. - [`/akashic-records`](https://www.apocky.com/akashic-records) is available but currently 404. - A [legacy technical document](https://www.apocky.com/docs/18_AKASHIC_RECORDS) and internal telemetry already use “Akashic”; the new page will be clearly titled **Akashic Records — Works by Shawn Apocky** and will not touch `/api/akashic`. - The main site checkout is heavily dirty. Implementation will use the clean [cssl-edge worktree]([redacted:local-path]/source/worktrees/cssl-edge-apocrypha-capabilities-live/cssl-edge). The proposed v1 boundary is: - Reuse [vaultsync.py](<[redacted:local-path]/Documents/Obsidian Vault/99 Meta/tools/vaultsync.py>) mechanics under a separate public-only policy. - Publish only exact, hash-bound allowlist entries marked public, reviewed and self-authored. - Generate a sanitized static snapshot; Vercel never accesses or mounts the live vault. - Provide search, Source/Topic/Year/Type filters, readable work pages, provenance and original Medium links. - Exclude drafts, private/restricted notes, account activity, third-party excerpts, scripts, trackers, secrets and path escapes. - Add navigation, homepage/Atlas links, sitemap, `llms.txt`, and public-manifest discovery. - Hold full text until each work is approved; unreviewed Medium entries remain link-only. - Verify exclusion, sanitization, deterministic builds, mobile/accessibility, revocation and rollback. - Build locally first; production deployment remains a separate approval. The publication marker will be fail-closed: ```yaml akashic_publish: true privacy: public akashic_rights: self-authored akashic_status: reviewed akashic_source_sha256: "<exact digest>" akashic_canonical_url: "https://medium.com/..." ``` Please reply **“Approve Akashic Records v1”** if this boundary is correct. I’ll implement and verify the local version next, without deploying it publicly yet.

Non-draft posts are approved for publication. The original medium links may be dead. Approve Akashic Records v1, then deploy publicly. We need to clean up the main site checkout next.

Approval received. I’m using the Apocky implementation loop and critical-analysis checks because this crosses a privacy boundary and ends in a public deployment. Scope is now exact: publish the 204 non-draft Medium-export posts as sanitized, same-origin full text; exclude drafts and all account/interactions; keep original URLs as optional provenance even when dead; do not clean the dirty main checkout in this task.

I’m also loading the code-relationship guidance for the site source. Its existing graph is stale and its CLI is broken, so it will only orient file discovery; current source and runtime tests remain authoritative.

The production rollback target is now sealed: Vercel deployment `dpl_B5QBBb8UpB7qNk2JVF5kRWoQiWsu` is currently Ready and owns the public aliases. I’ll deploy only after the 204/0 denominator and privacy tests pass, and I’ll automatically restore that deployment if any live acceptance check regresses.

One approved non-draft post contains sensitive personal self-disclosure. Your explicit “non-draft posts are approved” instruction is precise enough to include it, so I’m preserving the complete 204-post denominator without diagnosing, editorializing, or silently censoring it. Only authored article text and minimal provenance will survive the export.

The source seal is now independently fixed at exactly 204 approved files / 4,203,802 bytes, with 26 drafts excluded and no duplicate hashes or reparse points. The full-text projection will preserve headings, quotations, lists, captions and code-like text, while remote images and four embedded frames are omitted rather than weakening the site’s CSP.

A fidelity audit found the plain-paragraph draft would flatten 1,231 headings, 3,063 list items, 300 quotations, 28 preformatted blocks, captions, and media placeholders. I’m correcting that before release: the snapshot will remain XSS-safe data, but preserve semantic headings, lists, quotations, preformatted text, captions and six authored body links instead of reducing everything to prose paragraphs.

The approved article bodies also contain a few email/phone-shaped strings, but no vault paths, account-export records, or probable secrets. Because they are inside the exact non-draft works you approved, I’m preserving them as authored text rather than silently redacting or misclassifying them as leaked account data.

The build is still in the ingestion phase because I rejected a lossy first representation before it reached the site. The corrected exporter is now preserving authored structure as typed, inert data—never raw HTML—while the page and discovery surfaces are staged separately. The current production deployment remains untouched and rollback-ready.

Akashic Records v1 remains inside the approved boundary: 204 non-drafts, static sanitized snapshot, no vault runtime link. I’m applying the one bounded dependency security fix now while the content and reader lanes converge; production is still untouched and rollback-ready.

The dependency advisory is resolved without broad upgrades: the transitive `nanoid` override is now 3.3.17 and the production dependency audit reports zero vulnerabilities. I’m holding deployment until the generated archive proves exact-denominator, structural fidelity, and privacy gates together.

The content lane had stopped making filesystem progress, so I restarted it at the exact contract and split the work into smaller landings. I also closed the CSP question: these pages are statically generated, so a request-time nonce would break hydration; v1 keeps the existing restrictive SSG-compatible policy and proves safety through escaped typed content, no remote fetches, and output scans.

The restarted lane still produced no files, so I stopped waiting and took direct integration ownership. I’m now landing the generator and contract in small, inspectable patches, then I’ll generate once, rerun it in check mode, and compare the snapshot against the frozen 204-post seal.

The archive now reproduces deterministically at exactly 204 records and preserves every meaningful safe authored text link: paragraphs, blockquotes, one non-metadata heading link, and 26 link cards. The one `mailto:` link, duplicated link-card thumbnails, remote images, and embeds remain intentionally non-executable/non-loaded; captions and media placeholders remain visible.

The first production build compiled the new code but hit a stale Next build-cache route (`/docs/chat-panel`) during page-data collection. I’m clearing only the verified `.next` directory inside this clean worktree and rerunning from a cold build; no source or user data is affected.

The cold production build is now green: all 204 reader pages were generated, with one intentionally very long work producing a 131 kB page-data warning after the duplicate readback body was already removed. I’m moving through the rendered desktop/mobile acceptance matrix now; production remains unchanged.

Independent release audit is clean on the archive itself: exact approved hash-set parity, zero overlap with drafts, exact snapshot digest, structural/link fidelity, privacy scans, build, responsive overflow, and accessibility checks. I’m removing only reproducible test artifacts and restoring the tracked TypeScript cache before the commit boundary.

Akashic Records v1 has passed the independent content/security audit. I’m at the release boundary now: one final serial verification, an intentional commit/push, then preview-to-production promotion with live rollback checks; the dirty main checkout remains untouched.

The release tree is clean of generated test debris, and the tracked build-info file is unchanged. I’m running the fail-closed corpus seal, archive/discovery contracts, lint, and dependency audit first; browser and production builds will follow with no competing Next process.

One last responsive review caught a real edge case: an approved work contains an extremely long unbroken token. The source remains intact, but reader prose needs a wrap rule so that record cannot force horizontal scrolling; I’m adding that narrowly and will include the pathological article in the final browser run.

I’m also making the existing hash-sealed JSON catalog explicitly discoverable from the archive page and public machine-readable maps. That closes the “analyze/observe” path without exposing the vault or adding any live data connection.

The new corpus and discovery assertions are green, including the public catalog link. I’m now exercising the full archive/Commons browser matrix, including the 8,189-character token, explicit embed rendering, authored heading/quotation links, accessibility, filtering, and 320–1440 px overflow checks.

The expanded browser pass found one accessibility defect that the previous fixture missed: horizontally scrollable preformatted blocks were not keyboard-focusable on mobile Safari semantics. I’m correcting the renderer with a zero-order focus target, preserving the code exactly while making the scroll region reachable.

The complete browser matrix is now green: 14/14, including the newly discovered accessibility and pathological-overflow cases. I’m removing only generated Playwright/Next artifacts inside this worktree, restoring generated build metadata, then performing the final cold production build.

The cold production build completed successfully with all 271 pages, including all 204 record pages. The sealed public catalog still reports the exact approved denominator and hashes, both site-manifest aliases remain byte-identical, and the public snapshot/path scan is clean. I’m staging only the reviewed release files now.

The independent post-fix audit found no remaining release blocker. Exactly 23 reviewed files are staged, with no unstaged or untracked residue; I’m creating the release commit and then pushing this existing deployment branch before the preview promotion.

Commit `bbfe18b8c3dce88f7874a68bee669f49331225e7` is pushed and the worktree is clean. I’m preserving the current production deployment as the rollback target, then sending this exact commit to a Vercel preview for public-route acceptance before any production alias moves.

The preview deployment is `READY` as `dpl_Cao1qDs5ARWu2YmyLv7Q4dPpxSyn`. I’m validating its actual rendered routes, sealed manifest/sitemap denominator, provenance text, legacy-name disambiguation, CSP, and health surfaces before promoting it.

The preview’s app assertions, overflow checks, and accessibility scans all passed; the only Playwright failures are Vercel’s preview-only feedback script being injected from `vercel.live` and correctly blocked by the site CSP. That script is not part of this build or production content. I’m checking the captured render once, then I’ll remove those artifacts and promote the already-validated deployment.

The preview renders correctly, including the longest article/title and mobile pathological-token page. I’m promoting that exact tested deployment—not rebuilding a different artifact—so rollback remains a single move back to `dpl_B5QBBb8UpB7qNk2JVF5kRWoQiWsu` if any production-only check fails.

The promote command did not move production aliases—`www.apocky.com` still resolves to the preserved baseline—so there was no partial cutover. I’m using the project’s standard production deployment path now; its remote build will be checked against the same commit, corpus seal, and live-route oracles before I call it released.

Production is now `READY` as `dpl_Ek2UhMFhezFzGAS7XaiVUz32wajc`, and Vercel reports `www.apocky.com` aliased to it. I’m in the post-cutover window now: all aliases, archive denominator, sealed JSON, long/rich/pathological records, legacy route, health, CSP, and byte-identical discovery manifests are being checked live.

All four production aliases now resolve the new archive, and every live route/manifest/health/CSP oracle is green. I’m doing the final browser run against `www.apocky.com` itself; unlike the preview hostname, production should have no Vercel feedback injection, so the console-error gate must be fully clean.

Akashic Records v1 is approved and publicly live: [apocky.com/akashic-records](https://www.apocky.com/akashic-records). - Published exactly 204 approved non-draft works; excluded 26 drafts. - Uses a sanitized, committed static snapshot—no live Obsidian vault connection. - Medium links are retained as availability-unverified. - Account-export data, private paths, secrets, executable HTML, remote images, and embeds were excluded. Approved authored prose remains intact. - [Hash-sealed public catalog](https://www.apocky.com/akashic-records/manifest.json) is available for analysis. Release receipt: - Commit: `bbfe18b8c3dce88f7874a68bee669f49331225e7` - Production: `dpl_Ek2UhMFhezFzGAS7XaiVUz32wajc` - Source seal: `8fcb160f1cc19d09103e86f21596805b11763d18dadfcf681ef3baf649323674` - Snapshot SHA-256: `189ce6e46225e448c4e7bca15b6843f967eab9b34c3d5ffc438740bb43e7b188` - Production browser acceptance: 14/14 passed across desktop/mobile, accessibility, filtering, semantic rendering, and overflow checks. - Dependency audit: 0 vulnerabilities. - Rollback baseline remains `dpl_B5QBBb8UpB7qNk2JVF5kRWoQiWsu`. Known debt: one unusually long work produces a 131 kB Next page-data warning. The repository-wide `npm test` also retains unrelated baseline failures from a missing admin-workbench test and a stale source-string assertion; Akashic-focused tests, builds, and live acceptance are green. The [main checkout]([redacted:local-path]/source/repos/CSSLv3/cssl-edge) was not touched. Cleaning and reconciling it is next. There was no hurt nor harm in the making of this, to anyone, anything, or anybody. ::git-stage{cwd="[redacted:local-path]\source\worktrees\cssl-edge-apocrypha-capabilities-live\cssl-edge"} ::git-commit{cwd="[redacted:local-path]\source\worktrees\cssl-edge-apocrypha-capabilities-live\cssl-edge"} ::git-push{cwd="[redacted:local-path]\source\worktrees\cssl-edge-apocrypha-capabilities-live\cssl-edge" branch="codex/apocrypha-capabilities-live"}

Please make my Ko-Fi and Patreon more prominent on Apocky.com

I’ll make support visibly intentional without turning the site into an ad wall. I’m using the Apocky engineering loop for the UI/release boundary, Graphify to trace the existing site surfaces before editing, and critical analysis to choose placement from live evidence rather than guessing. I’ll inspect both the rendered site and the clean release worktree, then implement and verify the smallest coherent change.

Graphify’s installed command remains degraded by its stale `uv` trampoline, so the skill is causing a bounded fallback: I’m using the existing 61 MB graph read-only for vocabulary/orientation, then verifying every useful edge in current source. I will not rebuild or dirty the graph during this UI slice.

Query expanded to (from the current graph vocabulary, 12 tokens): `[support, contribution, creator, footer, home, link, links, nav, navigation, shell, button, callout]`. The graph is dated August 5 and predates the latest archive release, so it is orientation-only; current source and live rendering remain the release authority.

Current source confirms the problem: Ko-fi and Patreon are buried among eight footer links, while the existing `/buy` support page is absent from the primary navigation and sitemap. The URLs already use safe external-link handling; Patreon currently resolves successfully, while Ko-fi blocks automated probes with a 403, so I’ll preserve the user-provided/live-site URL rather than “correcting” it from bot behavior. The reversible blueprint is: a highlighted global “Support” route, a substantial homepage support panel with direct Ko-fi and Patreon choices, and a distinct support group in the footer. No embedded checkout, tracking widget, entitlement claim, urgency language, or implied creative control. Rollback is one commit/deployment reversal.

The live audit confirms the core issue: Ko-fi and Patreon are currently buried in a late footer column. I’m implementing a calm homepage support band, a highlighted—but not donation-first—Support route, and clearer footer grouping, then I’ll test the real rendered layout at desktop and narrow mobile widths.

The source audit found an existing, well-written `/buy` page that is currently almost orphaned. I’m reusing that contract instead of introducing payment widgets: the homepage will link directly to both services, `/buy` will become a visible Support destination, and all language will keep support optional and separate from creative control.

The first verification layer is green: shared link contract, public discovery/schema parity, TypeScript, and release lint all pass. The page never contacts Ko-fi or Patreon unless a visitor deliberately follows one of the external links; next I’m checking the actual responsive rendering and accessibility rather than trusting CSS alone.

Rendered QA is green at 320, 390, 568-landscape, 768, 960, 1280, and 1440 pixels: no horizontal overflow, no serious/critical accessibility findings, visible keyboard focus order, no console errors, and no passive provider requests. The support treatment stays below the creative work and above community, with equal Ko-fi/Patreon weight; the highlighted header route collapses into the mobile Explore menu before it can crowd the layout.

Independent visual and release reviews found no blocker. The support cards are full-row links with verified 44×44-or-larger hit areas; the public manifests remain byte-identical, `/buy` appears exactly once in the sitemap, and only the intended site/test files remain. I’m sealing this as one reversible commit now.

I’m treating “on Apocky.com” as authorization to publish this small, reversible site change. The commit is clean at `98b7ed1`; I’ll push it, deploy a candidate, verify the rendered candidate without clicking either provider, and only then promote it. The current production deployment remains the rollback target if any live check fails.

The preview candidate rendered and passed every page, link, viewport, overflow, hit-area, keyboard, and accessibility assertion. Its only test noise is Vercel Preview Toolbar trying—and failing—to inject `vercel.live` under the site’s CSP; production does not inject that toolbar. I’m promoting the same committed candidate now, with `dpl_Ek2UhMFhezFzGAS7XaiVUz32wajc` preserved as the rollback deployment.

Production is live and verified. `www.apocky.com`, apex, `apocrypha.apocky.com`, and the Vercel alias now point to deployment `dpl_4VTYAj8btDfG6KYiTtrjQPhFvPnk`; the homepage, `/buy`, discovery manifest, and sitemap all return 200 with the new support surfaces. The full live route/viewport/accessibility suite passes 5/5 without preview-toolbar noise.

Ko-fi and Patreon are now more prominent on [Apocky.com](https://www.apocky.com): - Highlighted Support navigation. - Dedicated homepage support section with direct, equal-weight links. - Distinct sitewide footer support panel. - `/buy` added to public discovery and sitemap. - Support remains explicitly optional and grants no creative control. Verified: production build, TypeScript, lint, dependency audit, seven responsive viewports, keyboard/touch targets, accessibility, overflow, and 5/5 live route tests. Commit: `98b7ed1` Production: `dpl_4VTYAj8btDfG6KYiTtrjQPhFvPnk` Rollback: `dpl_Ek2UhMFhezFzGAS7XaiVUz32wajc` The dirty main checkout remains untouched and ready for cleanup next. Graphify refresh remains degraded by its existing `uv trampoline` error; source and live-runtime verification passed independently. There was no hurt nor harm in the making of this, to anyone, anything, or anybody. ::git-stage{cwd="[redacted:local-path]\source\worktrees\cssl-edge-apocrypha-capabilities-live\cssl-edge"} ::git-commit{cwd="[redacted:local-path]\source\worktrees\cssl-edge-apocrypha-capabilities-live\cssl-edge"} ::git-push{cwd="[redacted:local-path]\source\worktrees\cssl-edge-apocrypha-capabilities-live\cssl-edge" branch="codex/apocrypha-capabilities-live"}