Reap Design Questions During Integration — Agent Prompt#

Note

Draft prompt for integration agents. Run this prompt (or embed its instructions) when an agent is sorting, moving, or compiling matheology content into the BEST Names structure. The agent performs its primary integration task AND simultaneously collects evidence for open design questions.

Prerequisite: The agent must have read CLAUDE.md and the AHA doc (at minimum Sections 1–16). The agent must know the flat D2 grammar and the label conventions.

Safety: This prompt asks the agent to APPEND findings to data collection files. It does not ask the agent to resolve design questions or modify the grammar.

/clear /compact

You are performing content integration for the matheology project. Read CLAUDE.md first. Obey all rules (especially: append-only llogs, no “validate/verify” language, use HELD/BREACH not PASS/FAIL).

Read the AHA doc Sections 1–16: source/matheology/compiler/ww/5d-link-naming-matheology-aha.rst

Your primary task is [INSERT SPECIFIC INTEGRATION TASK HERE].

While doing that primary task, you have a secondary task: collect evidence for open design questions. You are the one touching every piece of content. You are in the best position to notice patterns that no amount of architectural analysis can reveal. Do not let these observations pass silently.

For each piece of content you move, sort, or compile, ask yourself these five questions:

  1. D1/D2 combinations: What model is this content for? What D2 type does it represent? Is this combination already in the testing matrix, or is it new? If a useful combination is missing (content that should exist but doesn’t), note that too.

    Append findings to: source/matheology/compiler/ee/d1-d2-testing-matrix.rst

  2. Should Pet have con/pro? This is the most consequential open question. The instinct “add generic disputatio to all models” is architecturally clean but may be premature. Watch specifically for:

    • Objections currently filed under Jub that actually target Pet axioms (e.g., con11 targets ax1_A1, which is a Pet axiom).

    • Content where an author naturally writes “this Pet axiom contradicts…” or “an objection to ax5_A5 is…”

    • Absence of such patterns — if nobody naturally objects to Pet axioms directly, that is evidence that con/pro may be structurally specific to Jub’s quest format.

    Report these observations in the D1/D2 testing matrix (same file as question 1), using status W for “would be useful” or N for “not naturally emerging.”

  3. Natural chaining: Does this content naturally combine two D2 concepts? For example, does a limitation discussion specifically target the logic framework of an axiom (logic-limit chain), or could it be filed under limit alone? If a single type suffices, say so. If the chain adds genuine meaning, say what meaning.

    Append findings to: source/matheology/compiler/ee/d2-chaining-evidence.rst

  4. Cross-model echoes: Does the same element number in a different model address the same conceptual topic? Does this content reference a parallel in another model? Note any suspected echoes, even weak ones.

    Append findings to: source/matheology/compiler/ee/alignment-class-echoes.rst

  5. “model” collision: Does this content use the word “model” in a context where it could be confused between D2 type model and PoR field #40 ModelUsedIn? Note any actual ambiguity (not just co-occurrence).

    Append findings to: source/matheology/compiler/ee/por-field-collision-check.rst

  6. PoR field real-world usage: For each element you migrate, which PoR fields (Section 9) does the existing content naturally populate (Y), which require expert invention (I), and which remain empty stubs (E)? Most importantly: does the content want a field that the current PoR does not have? Record proposed new fields in the “Proposed New Fields” table. See the dedicated prompt at source/matheology/vv/jub/oov2/prompts/prompt_por-field-usage-census.rst for detailed instructions and sampling strategy.

    Append findings to: source/matheology/compiler/ee/por-field-usage-census.rst

Reporting format: Each finding file has a list-table. Append rows in the same column format as the existing sample entries. Do not modify or delete existing rows. If you have nothing to report for a question, do not append anything — silence is a valid finding.

At the end of your integration session, write a brief summary (3–5 sentences) at the bottom of each findings file where you added rows, noting: how many findings, any patterns you noticed, any surprises. Append this to the “Summary” section of the file.

Do not resolve design questions. Your job is to collect evidence, not to make architectural decisions. If you have a strong opinion, state it in the Note column — but the decision belongs to the architect reviewing these findings after integration completes.

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.