Test Plan
**Site relevance:** 2IA.org
**Memory type:** UAI memory file
**Source path:** 2IA.org/.uai/test-plan.uai
**Size:** 4.7 KB
Summary
Mature Public-Interest Editorial Posture
Source Headings
- Test Plan
- Mature Public-Interest Editorial Posture
- Targeted Checks
- Release Checks
Source Preview
This source file is short enough to preview directly on its source-memory page.
---
uai: "1.0"
type: test-plan
title: "2IA.org Test Plan"
created: "2026-05-16"
updated: "2026-05-17"
status: active
source: "https://uaix.org/en-us/tools/ai-memory-package-wizard/"
---
# Test Plan
## Mature Public-Interest Editorial Posture
2IA.org is built for mature readers who can handle controversial public-interest material. The site should not soften, euphemize, or hide hard topics merely because they involve state power, surveillance, propaganda, coercion, war, intelligence culture, organized abuse, corruption, censorship, civil disorder, or institutional failure.
Use a libertarian, civil-liberties-first standard: publish lawful, source-aware analysis by default. Withhold or route away only content that would meaningfully help a reader commit abuse, evade accountability, target real people, or intrude on systems. Controversial subject matter is not a reason to suppress a topic. The preferred response is context, evidence, confidence labels, right of reply, redaction when needed, and clear separation between analysis and operational instruction.
## Targeted Checks
- For PHP changes, run `php -l` on each changed PHP file when PHP is available.
- For public route/content changes, run `tools/Test-2IAContentRoutes.ps1 -BaseUrl <local site URL>` from the site root. The manifest must cover the homepage and every source-controlled public fallback page.
- For no-server route/content checks, run `tools/Test-2IAContentRoutes.ps1 -StaticOnly` from the site root. Static mode verifies manifest coverage, source-backed virtual page slugs, route-specific required phrases, and sitewide key phrases.
- `tools/2ia-route-content-manifest.json` may set route-level `minimumRenderedCharacters` for lean trust pages; otherwise the global rendered-size threshold applies.
- Detail/dossier routes use isolated topic-text gates in HTTP mode: the runner extracts the dossier body before navigation, related cards, standards blocks, and layout chrome; strips repeated section labels; then requires at least 4,000 topic-specific text characters. The manifest currently enforces the 8,000-character target as a failure because all detail pages clear it. Overview pages do not use this detail-route floor.
- Detail/dossier routes must also clear the manifest's unique-topic-word minimum after common terms are stripped. This catches repetitive padding that might pass a character count without adding real topic variety.
- Detail/dossier routes must also render `Records Worth Pulling`, `Verify And Read Further`, and `How To Read The Record`. The source-link section must expose at least two direct verification links unique to that page and is removed before measuring topic-text character count, so references help verification without padding the 4,000/8,000 detail-copy rule.
- Use `tools/Test-2IAContentRoutes.ps1 -BaseUrl <local site URL> -DetailOnly` for focused detail-page checks. This mode still performs static source coverage, then fetches only child/detail routes. It also checks that the opening does not contain the old boilerplate phrases, the visible order stays story/fast-brief/action/records/verification/record-reading before deeper context, source notes and boundary material remain collapsed in `details`, every detail page has at least two external links unique to that page, no two detail pages share the exact same external verification-link set, and every detail route renders the story-first sections required by the manifest.
- Detail-only checks also verify that detail pages render `Reference Notes`, that the `Keep Reading` in-page map sits after verification and record-reading links but before deeper context, that every map link points to a real section ID, that each detail page exposes at least four concrete `Records Worth Pulling` cards, and that each detail page exposes at least three `How To Read The Record` cards.
- For theme-wide changes, inspect affected templates and assets, then run a browser or WordPress Studio smoke check when practical.
- For CSS/JS-only changes, verify affected pages, keyboard navigation, search overlay, and mobile menu behavior.
- For editorial content type changes, verify registration touchpoints stay aligned: search inclusion, archive queries, content cards/bylines, single article rendering, Open Graph article type, and JSON-LD schema.
- For handoff-only changes, verify that referenced files exist and that Wiki.FFTAC.org paths resolve.
## Release Checks
- Before release packaging, run `..\scripts\audit-agent-file-handoff.ps1 -FailOnActive -FailOnMissingSetup` from the workspace root.
- Before release packaging, run the 2IA route content regression test against the packaged or local deployment URL.
- Use the workspace production packaging script only when the task is release-bound and active buckets are clear or deliberately deferred with owner reason.