Phase 2I Integration Tests — Design Questions Requiring Real Data#
Note
Test prompt for deferred design decisions. This prompt should be run AFTER the Phase 2I integration scripts have processed real content. Its purpose is to gather empirical evidence for open design questions that cannot be resolved by analysis alone.
Context: The AHA doc (BEST Names architecture, Section 19.2) identifies several design questions deliberately deferred until real-world data is available. This prompt systematically tests each one.
Prerequisite: Phase 2I scripts (content integration, compilation) must have run at least once, producing compiled pages with real cross-references.
Safety: This is a read-only analysis prompt. It does not modify any files. Results should be appended to an llog entry.
/clear /compact
You are analyzing the matheology content to gather evidence for open design questions in the BEST Names architecture. Read CLAUDE.md first. Obey all rules (especially: llog append-only, no “validate/verify”).
Read the AHA doc Section 19.2 for the full list of deferred questions:
source/matheology/compiler/ww/5d-link-naming-matheology-aha.rst
Then execute each test below. For each test, report: (a) what you found, (b) whether it supports or opposes a specific design choice, (c) your recommendation.
TEST 1 — BREACH 1.7: D1/D2 Validity (Cross-Model Element Types)#
Search the entire source/matheology/ tree for every :ref: and
RST label (.. _) that combines a D1 model code with a D2 element
type. Build a matrix:
D2 type |
pet |
jub |
4be |
all |
|---|---|---|---|---|
ax |
? |
? |
? |
? |
th |
? |
? |
? |
? |
con |
? |
? |
? |
? |
pro |
? |
? |
? |
? |
(etc.) |
Fill each cell with: Y (exists and has content), E (empty/stub), N (not present).
Key questions to answer:
- 1a. Are there any
pet-con*orpet-pro*labels? If so, what content do they contain? Do they represent natural cross-model objections or are they accidental?
- 1b. Are there D2 types used by only one model? Which ones? Is the
restriction inherent (e.g.,
qfor quest is structurally Jub-specific) or accidental (nobody wrotepet-q1yet)?- 1c. Should Pet have a disputatio? Based on the content you find:
do objections to Pet axioms naturally emerge in the existing material? If so, where? If not, would creating them add value or just clutter?
- 1d. Recommend: should the naming system enforce D1/D2 validity
constraints, or leave the grammar syntactically permissive and rely on the registry linter for semantic warnings?
TEST 2 — Sub-Element Chaining#
Search for cases where authors wrote labels, headings, or prose references that naturally chain multiple sub-element fields. Examples to look for:
pet-ax5-logic-limit(constraint on logic framework)jub-th8-needs-feeds(feed requirements of dependency graph)Any heading or comment that describes an element in terms of two sub-element fields simultaneously
Key questions:
2a. How many cases of natural chaining did you find?
- 2b. For each case: could the same information be expressed with a
single sub-element field? (If so, chaining adds no value.)
- 2c. Recommend: support chaining in the parser, or leave it single-field
and revisit if the count grows?
TEST 3 — Alignment Class Echoes#
Compare element numbering across models. For each pair of models that have overlapping D2 types (e.g., Pet ax1–ax14 vs Jub ax15–ax25):
- 3a. Are there ANY elements where the same number in different models
addresses the same conceptual topic? (These are echoes.)
- 3b. If echoes exist: do they cluster around specific numbers? Is
there a natural “alignment class” size (4, 5, 7, 12)?
- 3c. Search for any prose references to “echo,” “alignment,”
“parallel,” “correspondence,” or similar cross-model language in existing content.
- 3d. Recommend: is the alignment class mechanism (
all7e, etc.) warranted by current data, or is it premature?
TEST 4 — dump Depth Usage#
Search for any existing pages, headings, or comments that serve a “show me everything” or “debug view” function:
- 4a. Are there pages that already aggregate all sub-element fields
for a single element? (These are proto-
dumppages.)
4b. Are there comments or TODOs requesting such pages?
- 4c. Recommend: is
dumplikely to be used in practice, or is it a theoretical convenience?
TEST 5 — PoR Field #40 Name Collision#
Search for all uses of the string model in label contexts
(RST labels, :ref: targets, PoR field references):
- 5a. How many times does
modelappear as a D2 element type (e.g.,
pet-model1) vs. as a PoR field name?- 5b. Is there any actual ambiguity in existing content, or is the
collision purely theoretical?
- 5c. Recommend: rename the PoR field now, or leave it until the
compilation skill makes it a real parse conflict?
TEST 6 — Cross-Model Objections in HELL#
Read the 33 con entries in source/matheology/hell/con/b/*/index.rst.
6a. How many objections are specific to Jub only?
6b. How many apply to Pet axioms as well (even if filed under Jub)?
- 6c. How many are truly cross-model (applying to the shared
foundation rather than any specific model)?
- 6d. Recommend: should cross-model findings use
all-con*labels, or stay under their discovering model and be cross-referenced?
SUMMARY#
After completing all tests, produce a summary table:
Test |
Question |
Evidence strength |
Recommendation |
|---|---|---|---|
1 |
D1/D2 validity |
(strong/weak/none) |
(enforce/permissive/defer) |
2 |
Sub-element chaining |
… |
… |
3 |
Alignment classes |
… |
… |
4 |
|
… |
… |
5 |
PoR field #40 |
… |
… |
6 |
Cross-model HELL |
… |
… |
Append the full results to an llog file:
source/matheology/vv/jub/oov2/llog/llog_{today}_integration-tests.rst