docs(blog): remove broken forward links and add publish dates

site/astro.config.mjs

@@ -156,14 +156,14 @@ export default defineConfig({
           label: "Blog",
           items: [
             { label: "All Posts", slug: "blog" },
-            {
-              label: "Why Your Agent Can't Audit Itself",
-              slug: "blog/daemon-process-separation",
-            },
             {
               label: "OpenClaw Plugin: How It Works",
               slug: "blog/openclaw-plugin-deep-dive",
             },
+            {
+              label: "The audit boundary belongs outside the agent",
+              slug: "blog/daemon-process-separation",
+            },
           ],
         },
       ],

site/src/content/docs/blog/daemon-process-separation.mdx

@@ -3,7 +3,7 @@ title: "The audit boundary belongs outside the agent"
 description: "The architectural problem with in-process receipt signing, and how daemon process separation restores the audit property."
 ---
 
-**Series: Auditing AI Agents** · Part 1 of 3 · Next: [One Chain, Two Channels, Zero Secrets →](/blog/unified-chain-redaction-demo/)
+_Published 2026-05-17_ · **Series: Auditing AI Agents** · Part 1 of 3
 
 ---
 
@@ -113,5 +113,3 @@ That signing key — `did:agent-receipts-daemon:local#k1` — lives only in the
 ## What comes next
 
 The daemon is the trust anchor for everything that follows: secret redaction before storage (already shipped), asymmetric payload encryption so only a forensic key holder can read stored inputs, centralised storage for cross-machine audit trails. All of it depends on having one trusted process that owns the keys and the chain.
-
-The next post is the demo — the unified chain and secret redaction working end to end, on real receipts.

site/src/content/docs/blog/index.mdx

@@ -7,4 +7,5 @@ Updates, deep dives, and field notes from building the Agent Receipt Protocol.
 
 ## Posts
 
-- [OpenClaw Plugin: How It Works](/blog/openclaw-plugin-deep-dive/) — Plugin architecture, receipt anatomy, self-verification, and how the OpenClaw integration differs from the MCP Proxy.
+- **2026-05-17** — [The audit boundary belongs outside the agent](/blog/daemon-process-separation/) — The architectural problem with in-process receipt signing, and how daemon process separation restores the audit property.
+- **2026-04-27** — [OpenClaw Plugin: How It Works](/blog/openclaw-plugin-deep-dive/) — Plugin architecture, receipt anatomy, self-verification, and how the OpenClaw integration differs from the MCP Proxy.

site/src/content/docs/blog/openclaw-plugin-deep-dive.mdx

@@ -3,6 +3,8 @@ title: "OpenClaw Plugin: How It Works"
 description: "Plugin architecture, receipt anatomy, self-verification, and how the OpenClaw integration differs from the MCP Proxy."
 ---
 
+_Published 2026-04-27_
+
 The OpenClaw plugin is the second way to generate Agent Receipts — the first being the [MCP Proxy](/mcp-proxy/overview/). Both produce the same W3C Verifiable Credentials with Ed25519 signatures and hash-chained sequences. They differ in where they sit and what context they have access to.
 
 This post covers the plugin's internal mechanics, using real receipts from the first end-to-end trial.