Phase 2I-5: Adversarial Stress-Test of BEST Names Architecture#

Note

Path update needed if rerun (2026-03-25, Phase 2I-3). This prompt was executed before the compiler directory was created. If this script is ever rerun, update the AHA doc path below.

Note

200K-token execution prompt. Copy-paste everything below the horizontal rule into a new Claude Code session.

Prerequisite: Phases 2I-1 through 2I-4 should have completed so the naming system is live in the codebase. However, this stress-test can also run in parallel with earlier phases as a design review.

Session goal: Attack the BEST Names architecture as hard as possible. Find every weakness, ambiguity, collision, and scalability problem. This is an adversarial session — your job is to BREAK the system, not defend it.

Token budget: ~110K. Uses selective reads for large files.

/clear /compact /effort max

You are executing Phase 2I-5 of the JUB OOv2 matheology project: an adversarial stress-test of the BEST Names architecture defined in the AHA design document.

Your role: attacker. Try to break the naming system. Find collisions, ambiguities, edge cases, scalability failures, and design contradictions. Be creative, rigorous, and relentless.

Do NOT defend the design. Do NOT suggest fixes during the attack phase. First enumerate ALL problems, THEN (and only then) propose fixes.

TOKEN BUDGET — SELECTIVE READ STRATEGY#

  • quest.rst (~48K tokens): You need the LABEL STRUCTURE, not the full content. Grep for all .. _con- and .. _pro- label definitions plus all :ref: references. Read 3-line context around each match. This gives you the complete label inventory for collision testing.

  • compiled pages: If they exist, read them in full (they should be moderate-sized). If they do not exist yet, note this and test against the design spec instead.

STEP 0 — READ THE DESIGN (DO THIS FIRST)#

ax1_A1. AHA DESIGN DOC (the full architecture to attack) — READ IN FULL: source/matheology/vv/jub/oov2/llog/aha-best-names-for-matheology-links.rst (New location: source/matheology/compiler/ww/5d-link-naming-matheology-aha.rst)

ax2_A2. PoR FIELD TESTING REPORT — READ IN FULL: source/matheology/vv/jub/oov2/llog/2I-por-field-testing.rst

ax3_A3. PET AXIOMS (live example of labelled content) — READ IN FULL: source/matheology/pet/axioms.rst

ax4_A4. JUB AXIOMS — READ IN FULL: source/matheology/jub/axioms.rst

ax5_A5. JUB QUEST (label structure only) — SELECTIVE READ: source/matheology/jub/quest.rst Grep for all label definitions and references. Do NOT read in full.

ax6_A6. SKILL SPECIFICATION (if it exists) — READ IN FULL: source/matheology/vv/jub/oov2/llog/skill-compile-matheology.rst

ax7_A7. COMPILED PAGES (if they exist) — READ IN FULL: source/matheology/compiled/axioms/expert.rst source/matheology/compiled/axioms/easy.rst (New location per DD-b12: source/matheology/axioms/expert/ and axioms/easy/)

STEP 1 — COLLISION ATTACKS#

Try to find label collisions. For each attack, show the specific labels that collide and why.

1.1 D1×D2 prefix collision: Can any model code equal any

element type code? Check all registered and reserved codes.

1.2 D2 bare vs. specific: Does pet-ax (collection) ever

collide with pet-ax0 or any other label? What if someone creates element 0?

1.3 Cross-dimension collision: Construct a label where two

different dimension combinations produce the same string. E.g., is pet-ax5-de ambiguous between “depth=de” and “language=de”?

1.4 D5 view/source collision: Can any v* code equal any

s* code? Can any D5 code collide with D4, D6, or D7?

1.5 D6 Set A / Set B boundary: The proof says 2-letter

double-letter (POST) and 3+ letter (analytical) can’t collide. Test this. What about the ma* prefix for machine codes vs. analytical codes starting with “ma”?

1.6 D7 language + D6 POST: The design acknowledges aa/ff/ii

collisions. Are there any others? Check ALL ISO 639-1 codes against ALL D6 codes.

1.7 Future model codes: If a new model is named “ax” or “th”

or “all”, what breaks? Does the design prevent this?

1.8 Quest label collisions: The migration maps

con-a-2-1 → jub-con2r1. Does r as a round separator collide with any other use of r in labels?

STEP 2 — PARSING ATTACKS#

Try to break the LL(1) parser claim.

2.1 Ambiguous tokenization: Given the label

pet-ax5-oov2-easy-vjud-net-de, can an LL(1) parser unambiguously identify each dimension? Show the parsing steps or show where it fails.

2.2 Unknown tokens: What happens when the parser encounters an

unregistered code? E.g., pet-ax5-xyz. Is xyz a version, depth, view, state, or language?

2.3 Optional dimension ordering: The grammar says the order is

fixed (version, depth, view, state, language). But what enforces this? Can someone write pet-ax5-de-easy and have it silently resolve to something wrong?

2.4 Digit ambiguity: pet-ax5 has element+number. What

about pet-ax55? pet-ax555? Is the boundary between element code and number unambiguous for ALL D2 types?

2.5 Hyphen in version codes: oov2 contains no hyphens,

but could a future version code contain one? What breaks?

STEP 3 — SCALABILITY ATTACKS#

Project the system forward in time and scale.

3.1 1000 axioms: If the system grows to 1000 axioms across

20 models, does the label grammar still work? Any length limits in Sphinx?

3.2 100 languages: Currently 10 languages. At 100, does the

suffix approach still work? Any performance issues?

3.3 50 worldviews: The design has 14 views and 9 sources.

At 50+ views, does the D5 space remain navigable?

3.4 Version accumulation: After 50 versions, does the VV

archive become unmanageable? What’s the archiving strategy?

3.5 Combinatorial explosion: With 25 axioms × 5 depths ×

23 views × 14 states × 10 languages = 402,500 possible pages. The stub policy says “don’t generate empty pages.” But how does the system know which combinations are meaningful?

3.6 Build time: At what point does Sphinx build time become

prohibitive with this many cross-references?

STEP 4 — HUMAN-FACTORS ATTACKS#

Test whether real people can use this system.

4.1 Label memorability: Can a human remember

pet-ax5-oov2-easy-vjud-net-de? Is this humane?

4.2 Prose reference confusion: The prose convention says

“Pet ax5_A5” for first mention. But what if discussing Pet and Jub ax5_A5 in the same paragraph? Is “Pet ax5_A5 and Jub ax5_A5” clear enough?

4.3 Beginner onboarding: A new contributor opens the repo.

How many documents must they read to understand the naming system? Is this barrier acceptable?

4.4 Worldview sensitivity: The D5 codes assign 3-letter

abbreviations to religious traditions. Is visl for Islam potentially offensive? Is vind for Indigenous appropriately respectful? Review all codes for sensitivity issues.

4.5 Error messages: When a :ref: fails because of a typo,

what does Sphinx show? Is the error message helpful enough to diagnose which dimension is wrong?

STEP 5 — DESIGN CONTRADICTION ATTACKS#

Look for internal contradictions in the AHA document.

5.1 DRY vs. compilation: The design says “single point of

truth in PoR.” But compiled pages copy/transform content. If the PoR changes and compilation isn’t re-run, compiled pages are stale. Is this a real DRY violation?

5.2 Include ban vs. reality: The design bans .. include::

for labeled content. But the existing axioms/index.rst still uses it. How long can this coexist?

5.3 Language-last rule: Language is always last. But Sphinx

i18n (locale/) works by building separate language trees. Does the RST-level language suffix conflict with Sphinx’s built-in i18n mechanism?

5.4 Machine codes in D4 vs. D6: The design puts machine codes

(ma*) in D4 (depth) but mentions them in D6 (state) for collision proofing. Are they in D4 or D6?

5.5 Reserved codes: evx, ref, ex are reserved in

D2. all is reserved in D1. But ref also appears in D6 (analytical code) AND in the extraction matrix keyword list. Is ref overloaded?

STEP 6 — WRITE THE ATTACK REPORT#

Create a new file: source/matheology/vv/jub/oov2/llog/2I-adversarial-stress-test.rst

Contents:

  1. Title: “Phase 2I-5: Adversarial Stress-Test of BEST Names Architecture”

  2. Generated-by line with date and model

  3. Attack inventory: Every attack from Steps 1–5, numbered. For each attack:

    1. Attack description

    2. Result: HELD (system withstood this attack) or BREACH (real problem found — with constructive counterexample)

    3. Severity (if BREACH): Critical / Major / Minor / Cosmetic

    4. Evidence: the specific labels, codes, or scenarios

  4. Summary statistics: Total attacks, HELD count, BREACH count by severity

  5. Proposed fixes: For each BREACH, propose a minimal fix. Do NOT propose fixes for HELDs.

  6. Overall assessment: Is the architecture sound enough for Phase 3 deployment, or does it need another design iteration?

STEP 7 — UPDATE LLOG INDEX#

Add the stress-test report to the toctree in: source/matheology/vv/jub/oov2/llog/index.rst

Under the “Phase 2I: Post-Processing” section.

CRITICAL RULES#

  1. llog files are APPEND-ONLY.

  2. NEVER delete content files.

  3. NEVER abbreviate prompts in llogs.

  4. Your job is to ATTACK, not defend. Be the adversary.

  5. A “HELD” means you tried hard and couldn’t break it. Not that you didn’t try. Use HELD/BREACH, not PASS/FAIL (see “Not Validated but Tested” in the stress-test report for rationale).

  6. Show your work. Every attack must include specific labels, codes, or scenarios — not just hand-waving.

  7. LANGUAGE RULES: a. NEVER use bare “Jubilee” as standalone noun. b. NEVER use “the” for unproven superlatives.

TELES migration report (2026m04d04)

Mechanical identifier migration applied to this file. All axiom/theorem text references were migrated from short form (e.g., A15) to compound form (e.g., ax15_A15) as part of the matheology compound naming operation. Both forms refer to the same formal object. The old form survives as the suffix to ensure consistency with the oldest records; the new form adds a temporary-status prefix. Forward-facing pages use brief form (ax15) only. See TELES Axiom/Theorem Compound Naming — Execution Prompt for the complete mapping table and DD b12 — Legacy Naming for PET/JUB Axioms and Theorems for the permanent reference.

TELES repair — 2026m04d04

Repaired RST syntax errors (unexpected indentation, heading level inconsistencies, or list formatting). No formal content was modified.