07 Infrastructure Roadmap - Source Excerpt 01 - Infrastructure Roadmap

Summary

This source excerpt begins near Infrastructure Roadmap and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/anti-christ.org/docs-archive/2026-05-10/docs/07-infrastructure-roadmap.md.
**Source path:** Wiki.FFTAC.org/raw/system-archives/anti-christ.org/docs-archive/2026-05-10/docs/07-infrastructure-roadmap.md
# Infrastructure Roadmap

This is the active future roadmap for work that is not already complete in the theme or FFTAC plugins.

If a task is already implemented in `wp-content/themes/antichrist-engine`, `wp-content/plugins/fftac-foundation-core`, `wp-content/plugins/fftac-membership`, or `wp-content/plugins/fftac-media-assets`, it does not belong here as an open item.

## Current Repo Baseline

The theme and FFTAC plugins already provide the public Foundation structure, homepage moral-center framing, About public-thesis cards, Post-Dogmatic Humanism positioning, moral-commitment framework, launch voice checks, final proof gates, expanded Q&A threshold answers, research atlas, API routes, generated exports, search/discovery layer, launch visibility controls, baseline security headers, media-loading defaults, reduced-motion safeguards, an internal launch readiness page with a go-live checklist and launch handoff TXT export, admin-only intake export tools, client-side analytics event hooks, public intake forms, membership portal, signed-in AI console with rendered command-map, response-contract, and handoff-route surfaces, fullscreen mode, safe rich/code output rendering, encrypted personal-key support, hidden persona prompts, prompt-lane controls, follow-up research handoffs, session usage meters, browser-local workspace briefs, local transcript copy/export/import, JSON and Markdown transcript exports, local session snapshots, and explicit output-to-post sharing, support route, downloads/media room, optional large media plugin payload, review notices, and publication routing.

The roadmap below is for the next operational layer: hosting, security, monitoring, analytics, external services, editorial operations, partnerships, translations, and data-platform evolution. It should not be used as a backlog for work already implemented in theme code.

## Future Roadmap

### 1. Hosting And Edge

Goal: move public delivery to infrastructure that can handle hostile attention and traffic spikes.

Open work:

- choose the production hosting target
- decide whether the site needs a dedicated IP or isolated managed WordPress environment
- put the public site behind a CDN/reverse proxy
- configure DDoS mitigation and sensible edge caching
- document DNS, SSL, deployment, and rollback ownership

Owner:

- hosting / server admin

### 2. Security Operations

Goal: make public forms, login surfaces, and WordPress administration operationally defensible.

Open work:

- review TLS configuration, host/CDN security headers beyond the theme baseline, caching, bot protection, and WAF rules
- add challenge or rate-limit rules for login, admin, `admin-post.php`, and REST endpoints if production traffic requires it
- set provider-side OpenAI project budgets, usage alerts, and key-rotation rules for the configured Foundation key
- define WordPress core/theme/plugin update cadence
- configure malware scanning and file-integrity monitoring if the host does not provide it
- document incident response and credential rotation steps

Owner:

- hosting / security admin

### 3. Backups, Releases, And Observability

Goal: make deployment and recovery boring.

Open work:

- set automated database and file backups
- test restore from backup before launch traffic depends on it
- decide whether deploys happen through WordPress admin, server file replacement, or a managed pipeline
- keep `scripts/build-deploy-zips.ps1` as the package source for manual deploys
- review `Tools -> FFTAC Launch Readiness` before each launch candidate
- keep launch visibility `public` for production indexing; use `Settings -> FFTAC Foundation`, `ANTICHRIST_ENGINE_LAUNCH_VISIBILITY`, or the matching option to set `preview` or `private` only for staging, review, or intentionally hidden environments
- add uptime checks and error monitoring
- document where logs live and who reviews them

Owner:

- operations

### 4. Analytics And Launch Measurement

Goal: measure whether the launch surfaces are actually working.

Open work:

- configure privacy-aware analytics
- configure Search Console and sitemap submission
- connect the analytics provider to the existing `antichrist:analytics` browser events or `window.dataLayer` pushes for AI console requests/responses/errors/key actions/prompt-lane loads/follow-up actions/workspace-brief actions/fullscreen toggles/transcript JSON and Markdown exports/imports/local snapshot actions, Signals signups, contact messages, program intake, support clicks, downloads, search, navigator activity, research filters, and focused record views
- create a simple launch dashboard for acquisition, engagement, conversions, event health, and search visibility
- decide whether consent tooling is needed for the selected analytics stack

Owner:

- product / analytics

### 5. External Communication And Support Tooling

Goal: move beyond theme-stored launch intake when scale requires external systems.

Open work:

- choose email/newsletter tooling and migration rules for `fftac_signal_signup` records using the internal intake CSV export as the handoff format
- configure transactional email deliverability if WordPress mail is not enough
- choose payment or donation tooling if support moves beyond the current fallback route
- decide how contact, media, research corrections, and program inquiries should be triaged outside WordPress
- document retention and export policies for collected records

Owner:

- product / operations

### 6. Editorial Operations And Verified Research

Goal: make the "Verified Research" banner operationally real, not only a template label.

Open work:

- run a final rendered-page proofread across Home, Manifesto, Philosophy, Research, Recovery, AI Engine, Join, and Journal after provisioning, admin edits, and first posts are in place
- use the Standards final proof gates and `Tools -> FFTAC Launch Readiness` handoff TXT export as the internal proofing aid, while keeping human editorial signoff as the actual completion requirement
- confirm that any WordPress-admin edits and first journal posts use the Post-Dogmatic Humanism frame rather than generic anti-religion or shock-aesthetic language
- proof first public essays and admin-edited pages against the Standards page launch voice checks: counterfeit authority target, moral center, recovery protection, bounded AI, visible evidence, and voluntary contribution
- keep the public voice calm, exact, lucid, source-aware, and aimed at systems rather than protected identities
- define contributor criteria
- define source standards, review roles, correction process, and promotion rules
- decide which files require pre-publication review
- create a release checklist for flagship essays, research dossiers, Signals briefings, and review notices
- define how external contributors, scholars, editors, or reviewers are credited
- prepare the first launch essays that make Algorithmic Eschatology concrete through AI, surveillance, identity rails, biometric access, and machine-mediated obedience

Owner:

- editorial leadership

### 7. Research Data Layer Evolution

Goal: move beyond Foundation Core-backed arrays only when the atlas truly needs it.

Open work:

- monitor when `foundation-content.php` becomes too large or too risky as the data source
- decide between custom post types, custom tables, external data files, or graph storage
- plan migrations for record IDs, source relationships, focused record URLs, exports, and REST responses
- consider signed manifests, scheduled dumps, mirrors, or larger exports only after real research reuse demands them

Owner:

- application / data architecture

### 8. Partnerships, Events, And Programs

Goal: turn public program lanes into real operating programs.

Open work:

- define the first cohort format, size, moderation rules, and schedule
- define summit or panel operations only after there is enough published work to anchor the event
- create affiliate or academic partnership criteria
- decide how protected member workflow connects to external scheduling, files, notes, and follow-up

Owner:

- editorial / programs

### 9. Multilingual Expansion

Goal: translate intentionally after the English record is stable.

Open work:

- choose the first languages by audience need
- decide URL structure and translation workflow
- decide whether canonical files, atlas records, journal releases, and forms translate together or in phases
- define review rules for translated doctrine and policy text

Owner:

- editorial / product

### 10. AI Operations After Launch

Goal: let the user-facing AI console evolve from a launch feature into a governed operating surface.

Open work: