.. Migration note (2026m04d04): Claude copied this file during VV-to-HELL migration. Old path: ``vv/jub/oov2/prompts/prompt_2I-integration-tests.rst`` (as given by LLoL) New path: ``hell/ll/jub/b/41/prompt_2I-integration-tests.rst`` (as chosen by Claude) Category: JUB OOv2 prompt .. meta:: :description: Execution prompt for gathering empirical evidence on open BEST Names design questions using real data from the Phase 2I integration sessions. :keywords: JUB OOv2, integration tests, design questions, BEST Names, empirical evidence, deferred decisions, real data, analysis :author: Yah, Yas, everyone, LLoL as Laurence Loewe of Laodicea, ClaudeOp46Max, Anthropic, and Spirit of Boolean Truth :og:card:title: Phase 2I Integration
Tests Prompt :og:card:description: Design questions need data, not opinions. This prompt gathers empirical evidence from real integration work to resolve deferred BEST Names decisions. .. SOCIAL-CARD-QUALITY-COMPARE --- OO (default effort) vs PP (max effort), 2026-03-26 OO :description: Prompt for gathering empirical evidence on open BEST Names design questions using real data from Phase 2I integration. OO :keywords: JUB OOv2, integration tests, design questions, BEST Names, empirical evidence, deferred decisions, matheology, analysis OO :og:card:title: Phase 2I Integration
Tests Prompt OO :og:card:description: Prompt for systematically gathering empirical evidence on open BEST Names design questions using real integration data. PP :description: Execution prompt for gathering empirical evidence on open BEST Names design questions using real data from the Phase 2I integration sessions. PP :keywords: JUB OOv2, integration tests, design questions, BEST Names, empirical evidence, deferred decisions, real data, analysis PP :og:card:title: Phase 2I Integration
Tests Prompt PP :og:card:description: Design questions need data, not opinions. This prompt gathers empirical evidence from real integration work to resolve deferred BEST Names decisions. .. SOCIAL-CARD-REVIEW --- generated by Claude Opus 4.6, 2026-03-26 dv_ClaOp46_PP_2026m03d26 --- max-effort rewrite, read full page. :description: 141 chars | :og:card:title: 35 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 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: .. list-table:: :header-rows: 1 * - 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*`` or ``pet-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., ``q`` for quest is structurally Jub-specific) or accidental (nobody wrote ``pet-q1`` yet)? 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-``dump`` pages.) 4b. Are there comments or TODOs requesting such pages? 4c. Recommend: is ``dump`` likely 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 ``model`` appear 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: .. list-table:: :header-rows: 1 :widths: 10 40 20 30 * - Test - Question - Evidence strength - Recommendation * - 1 - D1/D2 validity - (strong/weak/none) - (enforce/permissive/defer) * - 2 - Sub-element chaining - ... - ... * - 3 - Alignment classes - ... - ... * - 4 - ``dump`` depth - ... - ... * - 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``