.. Migration note (2026m04d04): Claude copied this file during VV-to-HELL migration.
NOTE: This prompt also appears in b/41/ (dual placement per migration map).
Old path: ``vv/jub/oov2/prompts/prompt_2I-5.rst`` (as given by LLoL)
New path: ``hell/ll/jub/b/45/prompt_2I-5.rst`` (as chosen by Claude)
Category: JUB OOv2 prompt (also in b/41)
.. meta::
:description: Execution prompt for an adversarial session attacking the BEST Names architecture to find naming collisions, scalability flaws, and weaknesses.
:keywords: JUB OOv2, Phase 2I-5, adversarial, stress-test, BEST Names, naming collisions, scalability, architecture attack, weaknesses
:author: Yah, Yas, everyone, LLoL as Laurence Loewe of Laodicea, ClaudeOp46Max, Anthropic, and Spirit of Boolean Truth
:og:card:title: Phase 2I-5: BEST Names
Adversarial Attack
:og:card:description: Break it before it ships. This prompt drives an adversarial attack on the BEST Names architecture to find every collision and scalability flaw.
.. SOCIAL-CARD-QUALITY-COMPARE --- OO (default effort) vs PP (max effort), 2026-03-26
OO :description: Prompt for Phase 2I-5 adversarial stress-test attacking the BEST Names architecture to find weaknesses and collisions.
OO :keywords: JUB OOv2, Phase 2I-5, adversarial, stress-test, BEST Names, architecture, naming collisions, scalability, matheology
OO :og:card:title: Phase 2I-5: BEST Names
Adversarial Attack
OO :og:card:description: Prompt for an adversarial session attacking the BEST Names architecture to find every weakness and scalability problem.
PP :description: Execution prompt for an adversarial session attacking the BEST Names architecture to find naming collisions, scalability flaws, and weaknesses.
PP :keywords: JUB OOv2, Phase 2I-5, adversarial, stress-test, BEST Names, naming collisions, scalability, architecture attack, weaknesses
PP :og:card:title: Phase 2I-5: BEST Names
Adversarial Attack
PP :og:card:description: Break it before it ships. This prompt drives an adversarial attack on the BEST Names architecture to find every collision and scalability flaw.
.. SOCIAL-CARD-REVIEW --- generated by Claude Opus 4.6, 2026-03-26
dv_ClaOp46_PP_2026m03d26 --- max-effort rewrite, read full page.
:description: 143 chars | :og:card:title: 40 chars (excl
)
- [ ] PP title more compelling than OO title
- [ ] PP description more accurate than OO description
- [ ] Description hooks without misleading
- [ ] Keywords specific to this page's actual content
- [ ] No language rule violations
- [ ] Character counts verified
*********************************************************************
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:
a. Attack description
b. Result: HELD (system withstood this attack) or BREACH (real
problem found --- with constructive counterexample)
c. Severity (if BREACH): Critical / Major / Minor / Cosmetic
d. 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.
.. admonition:: 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
:ref:`hell-ll-other-b15-teles-renaming-prompt` for the complete
mapping table and :ref:`legacy-5d-link-names-table-for-pet-jub-model` for the permanent
reference.
.. admonition:: TELES repair — 2026m04d04
Repaired RST syntax errors (unexpected indentation, heading level inconsistencies,
or list formatting). No formal content was modified.