Futurum mechanicals

What changed since 2026-09-21 PRs #51–#63 and a probe fix

• ✓

  MCP discovery manifest shipped — bar item 9 closed

  /.well-known/mcp.json now serves and points at the live server; T2 went from 67% to 100%, and the server grew from 11 tools to 16.

  t2.wellknown_mcp 200, valid JSON, 6,074 bytes · servers[].url https://preview.erikbethke.com/api/mcp
• ✓

  MCP named in the first kilobyte of llms.txt — bar item 6 closed

  llms.txt was restructured (36 KB to 12 KB, index-first); the MCP endpoint now sits inside the first 1,024 bytes, where a truncating fetcher reads it.

  t1.llms_txt.first_kb_mcp MCP URL in first 1024 bytes: https://preview.erikbethke.com/api/mcp
• ✓

  Trailing-slash redirects no longer hang for 20 seconds

  Every 308 redirect was sending an empty streamed body that never terminated, so CloudFront waited out its 20 s origin timeout. Redirects now answer in about 0.4–0.5 s.

  before 308 20.42s /for-agents · 20.41s /products · 20.55s /methodology
  now 308 0.38s /for-agents · 0.46s /products
• ✓

  Markdown mirrors, negotiated at the edge

  Every page has a .md twin, negotiated at CloudFront. Agent-readiness Tier 3, done.
• ✓

  /ai4me, security.txt and a web app manifest

  All three now ship. security.txt lists security@futurumgroup.com and expires 2027-08-23.

  t1.ai4me 200, 3,980 chars server-rendered · t5.security_txt 200, 163 bytes · t5.manifest link=/manifest.webmanifest
• ✓

  The probe's false negatives are fixed

  repo.sitemap and repo.well_known failed only because the probe didn't recognise App Router route handlers. Fixed; both now pass on their own.
• ✓

  Runtime and stage hygiene

  The server Lambda runs Node 22 (the newest SST 3 accepts). Every non-prod stage serves noindex until cutover; only futurum-web-prod flips indexable.

Shipped and working the mechanicals that are done

The new build leads on every tier, and ships four capabilities the incumbent has none of.

What the new build ships that the incumbent does not

In the repo, as generated routes rather than static files

Every surface below is a real route that renders at request time, so it cannot drift from the content the way a hand-maintained file does. Repo checks: conformance 2 of 2, adoption 3 of 3.

Left to go nothing that can close before cutover

The one unmet bar item

• !

  13. GA4 or a named alternative, browser-verified

  The cutover hold above; the repo confirms the absence, and it is intended.

  t4.ga4 — GA4 measurement id: not in server HTML
  repo.ga_env_slots — no GA/GTM env slot found

Cutover checklist items that ride with it

• !

  GTM, Google Ads, Reddit and Meta pixels

  Same hold, same moment. Adoption warns only; none is scored.

  t4.gtm · t4.google_ads · t4.reddit · t4.meta_pixel — not in server HTML
• !

  Google Search Console verification

  Likely verified by DNS TXT, which carries over automatically. Confirm before cutover.

  t4.gsc_verification — no google-site-verification meta (may be verified by DNS TXT or file)
• !

  Flip noindex off

  Automatic: SITE_INDEXABLE is true only on futurum-web-prod.

Response time

• ✓

  t5.ttfb passes: 364 ms median of five (342–453 ms; the live site 391 ms) on a preview stage, not production

  Why the earlier warning is gone

  An earlier run graded one cold 964 ms sample as a warning. Three re-runs minutes later read 706, 408 and 403 ms, and all passed — the probe graded on a single request. Probe 1.0.3 (PR #71) discards one warm-up and scores the median of five. Production response time is measured at cutover, on the warm production path.

Security the September 2026 review

A white-hat security review ran on 2026-09-26: automated static analysis plus five independent, read-only reviews across the codebase, followed by two further pre-cutover passes. Every fix shipped as its own reviewed pull request, verified on a preview stage before merging. Nothing was deployed to production mid-review. There were no Critical findings.

Findings and fixes, by severity

Checked and found clean

Still open

• !

  Static-route CSP still allows inline scripts

  Not on this page — see above. A tighter, per-response script policy for the rest of the site's routes is planned next.
• !

  No one is subscribed to the new security alarms yet

  The four alarms added above fire correctly; routing one to an actual person is the remaining step.
• !

  Automated dependency-review scanning needs a platform feature enabled

  The scan itself is wired up; it is waiting on a repository-level security feature to be turned on.
• !

  A couple of small infrastructure cleanups, deferred to the account cutover

  A regional-configuration fix and an infrastructure-tooling upgrade are deliberately held for the move to Futurum's own hosting account. See the Cutover to-do tab.
• !

  The published security-contact mailbox needs confirming

  A Futurum mail administrator needs to confirm it exists and receives outside mail before production launches on it. See the Cutover to-do tab.

Publish to this site one core behind every door, live in seconds

Everything above measures whether machines can read this site. This is what lets Futurum (or an AI acting for Futurum) write to it: one checked, safe call that gets a new post live in seconds, with no rebuild and no deploy.

The exhibit is live: preview.erikbethke.com/insights/sample-insight-publishing-pipeline/, created exactly the way the curl example below creates one. A second exhibit went further and published a report about itself: preview.erikbethke.com/research-reports/agentic-research-reports/, a research report on agentic research reports, written and published by an agent through this exact pipeline.

You can publish directly to this site over HTTP. Read this whole block before you write any code, then follow it exactly — every rule below is enforced server-side, not a suggestion.

ENDPOINT
  Create  POST    https://preview.erikbethke.com/api/posts
  Update  PUT     https://preview.erikbethke.com/api/posts/<slug>
  Delete  DELETE  https://preview.erikbethke.com/api/posts/<slug>?kind=<kind>   (soft delete; append &force=true to hard-delete)

AUTH
  Authorization: Bearer <YOUR_TOKEN>
  A token looks like fxp_<id>.<secret>. You do not mint your own — it is issued
  by the site owner (see "For operators" below) and handed to you, usually as an
  environment variable.

IDEMPOTENCY
  Send an Idempotency-Key header on every write. Derive it from the request's own content
  — e.g. the slug plus a hash of the body — rather than a random value, so retrying
  after a timeout or a 5xx is always safe: the same key and the same body replay the original
  response with an Idempotent-Replayed: true header instead of creating a duplicate. The same
  key with a DIFFERENT body is refused outright (422 idempotency_key_reused) — mint a new
  key if the request is meant to change.

SUBMISSION BODY (POST and PUT), as JSON:
{
  "kind": "insight",                 // insight | news | press-release | research-report — "page" is not a post; pages stay in the git lane
  "slug": "your-post-slug",          // lowercase-kebab-case; fixed at creation, PUT cannot move it
  "title": "…",               // <= 300 characters
  "dek": "…",                 // <= 1000 characters; the one- or two-sentence summary
  "body": { "format": "html", "source": "<p>…</p>" },  // format is "html" or "markdown" — "canvas" is refused, see below
  "authors": ["a-person-slug", { "guest": "A Guest Name" }],  // optional; a guest is a name only, never a profile page
  "taxonomy": {
    "companies": ["nvidia"],         // slugs — an unknown company is rejected, not invented
    "practiceAreas": ["ai"],         // codes or slugs — unknown ones are rejected
    "featuredPeople": [],            // person slugs — must resolve
    "insightType": "…",       // optional, free text
    "verticals": [],
    "tags": ["free-text-tag"]        // created on first use
  },
  "seo": { "title": "…", "description": "…" },  // optional overrides only — there is no canonical override; the URL is derived from kind + slug
  "status": "draft"                  // draft | pending | publish
}

HTML RULES (format: "html")
  Only these survive a server-side sanitizer; everything else is stripped (with its contents,
  for script/style/iframe/object/form and the like) or unwrapped: p, br, hr, h2, h3, h4, ul,
  ol, li, blockquote, figure, figcaption, img, a, strong, em, b, i, u, s, sub, sup, code, pre,
  and the full table family (table, caption, colgroup, col, thead, tbody, tfoot, tr, th, td).
  h1/h5/h6 are demoted to h2/h4. <a> keeps only href/title/class; <img> keeps only
  src/alt/title/width/height — no onclick, no style, no target. Every href or src must be
  http(s), mailto:, tel:, a root-relative path, or a #fragment. A TABLE NEEDS REAL
  <table> MARKUP — there is no markdown-table support anywhere on this site.

MARKDOWN RULES (format: "markdown")
  No raw HTML tags and no { or } anywhere in the source — either one is refused outright.
  That also rules out a table in a markdown body (see above): use format: "html" instead.

NOT ACCEPTED HERE
  format: "canvas" is refused (422 canvas_not_supported). A canvas document is a complete
  standalone HTML page and needs a sandboxed renderer this lane doesn't have yet —
  that stays a git-lane, reviewed-pull-request thing.
  A future publishAt is refused (422 scheduling_not_available). Publish now, or leave status
  as draft/pending and have a person publish it later.

IF IT FAILS
  401 unauthenticated         the token is missing, malformed, or wrong — check Authorization
  403 forbidden               the token's principal lacks the capability this needs (e.g. it can create but not publish)
  409 duplicate_slug          that slug already exists for this kind — pick another, or PUT to the existing one
  422 scan_blocked            the body reads like a credential, an internal hostname, or similar — find it and remove it
  422 unknown_taxonomy        a company, practice-area or featured-person slug doesn't exist — drop it or fix it
  422 idempotency_key_reused  this key was already used with a different body — mint a new one
  429 (Retry-After: N)        over the daily quota — wait N seconds, then retry with the SAME idempotency key

NEVER include a credential, an internal hostname, or an unreleased customer name in a
submission — the server scans every field before it stores anything and blocks the
request outright when it finds one.

export SITE="https://preview.erikbethke.com"    # or your own site
export TOKEN="<YOUR_TOKEN>"

# Create a draft insight
curl -sS -X POST "$SITE/api/posts" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: my-first-post-v1" \
  -d @- <<'JSON'
{
  "kind": "insight",
  "slug": "my-first-post",
  "title": "My first post",
  "dek": "A short summary of what this post covers.",
  "body": { "format": "html", "source": "<p>Hello from an AI-assisted publish.</p>" },
  "taxonomy": { "tags": ["hello-world"] },
  "status": "draft"
}
JSON

# Replay: run the exact command above again, unchanged. The response comes back
# byte-identical, plus an Idempotent-Replayed: true header — nothing is created twice.

# Edit the title and publish it
curl -sS -X PUT "$SITE/api/posts/my-first-post" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -H "Idempotency-Key: my-first-post-edit-1" \
  -d '{"kind":"insight","slug":"my-first-post","title":"My first post, now live","dek":"A short summary of what this post covers.","body":{"format":"html","source":"<p>Hello from an AI-assisted publish.</p>"},"taxonomy":{"tags":["hello-world"]},"status":"publish"}'

# Soft-delete it (restorable); append &force=true to hard-delete instead
curl -sS -X DELETE "$SITE/api/posts/my-first-post?kind=insight" \
  -H "Authorization: Bearer $TOKEN" -H "Idempotency-Key: my-first-post-delete-1"

export FUTURUM_SITE_URL="https://preview.erikbethke.com"    # or your own site
export FUTURUM_PUBLISH_TOKEN="<YOUR_TOKEN>"

# Print the request and its Idempotency-Key without sending it
pnpm publish:post content/drafts/my-post.md --dry-run

# Publish it for real — frontmatter (kind, slug, title, dek, status, taxonomy…) becomes the Submission
pnpm publish:post content/drafts/my-post.md

# Edit the same file later, matched by its frontmatter kind + slug
pnpm publish:post content/drafts/my-post.md --update

# Issue a credential for a new agent, capped at 50 writes a day
pnpm publishing:principal create my-agent --role agent --caps create,publish --quota 50

# Revoke it
pnpm publishing:principal disable my-agent

Cutover to-do issue #121, the Polaris-account move

Issue #121: the security and infrastructure work for moving this site to Futurum's own AWS account, safer to do on a freshly created environment than to migrate in place. Every item below is still open.

Account and infrastructure

• !

  Region pinning

  A deployment-region setting needs to move to where the infrastructure tool reads it, so new stages are created in the right region from the start.
• !

  Move to the current major version of the infrastructure tooling

  New stages get created on the newer major version directly. Today's version carries developer-tooling advisories only; none reach the deployed site.
• !

  Confirm the security-contact mailbox

  A Futurum mail administrator needs to confirm it exists and receives outside mail before launch.

Email and DNS

added 2026-09-28, from a broader mail-security scan

• !

  Tighten the subdomain mail-spoofing policy

  The anti-spoofing mail policy covers the main domain but not subdomains yet; it extends once reporting confirms every legitimate sender is accounted for.
• !

  Review the domain's approved mail-sender list

  The approved-sender list is close to a technical lookup limit; retire unused senders before adding a new one.
• !

  Give any new site mail its own signed sender identity

  If the new site ever sends mail as Futurum — alerts, publishing notices — it gets its own signed sender rather than joining the shared list.
• !

  Retire or tighten the preview domain's mail policy

  The preview domain carries a looser anti-spoofing policy; retired or tightened alongside the account cutover.
• !

  Confirm the security-contact mailbox

  The same mail-administrator task as above — grouped here because it is the same person doing the same check.