PROMY:GROW — Generic Prompt Template#

Created:

2026-03-30

Origin:

First successful PROMY:GROW run on e7He

Status:

Draft — tested on one model, to be refined with experience

When to Use#

Use this prompt after PROMY:FEED has filled all gaps (symbols, predicates, cross-references) and you are satisfied that the model directory is complete and internally consistent. GROW applies changes that were agreed during FORGE TEMPER rounds but not yet integrated into the extracted files.

Prerequisite check before running GROW:

  • SEED completed (all statements extracted)?

  • FEED completed (symbols, predicates, cross-references audited)?

  • FORGE llog available and unchanged since SEED?

  • Model directory builds cleanly (make html succeeds)?

The Prompt#

Copy and adapt the following. Replace all {{placeholders}}.

PROMY:GROW {{MODEL_NAME}}

YOU ARE MODIFYING FORMAL MATHEMATICAL STATEMENTS.
This is the most dangerous step in the PROMY pipeline.

RULES:
- git commit BEFORE starting (clean baseline)
- For EACH change: show the EXACT old text and EXACT new text
- Do NOT apply any change without human approval
- If you find ANY inconsistency between the repair specification
  and the existing file content, STOP and FLAG it to the human
- git commit AFTER completing all approved changes
- Write the PROMY GROW llog to HELL when done

MAX EFFORT. Every character matters. An error here corrupts
all downstream uses of this model.


STEP 1: BUILD THE REPAIR INVENTORY
=====================================

Scan the FORGE llog at ``{{LLOG_PATH}}`` for all changes to
formal statements made during TEMPER rounds. Two methods:

**Method A (if MODEL_CHANGE markers exist):**

Search for ``MODEL_CHANGE:`` in the llog. Each marker has the
form::

  MODEL_CHANGE: <claim-id> | <type> | <target-file>

Collect all markers. This is the inventory.

**Method B (no markers --- scan by keywords):**

Search the ENTIRE llog for the following patterns. For each
match, read the surrounding context (~50 lines) to determine
whether a formal change was specified.

Keywords indicating formal changes::

  "Repair"  "Repaired"  "Fix"  "Fixed"
  "Change"  "Changed"   "NEW THEOREM"  "NEW AXIOM"
  "Rename"  "Renamed"   "Strengthen"  "Weaken"
  "Update"  "Updated"   "Replace"  "softened"

Section headers indicating change blocks::

  "Critical Repairs"  "Non-Critical Fixes"
  "CHANGE:"  "FORMALIZATION:"

StayC version bumps (vN → vN+1 indicates a change was made)::

  "OOv1 → OOv2"  "NN → OO"  "StayC:" with arrow

For EACH change found, record:

- **Claim ID** (e.g., m0.ax3, th3, sp1)
- **Change type** (repair, new, rename, strengthen, fix)
- **Llog location** (line numbers or section name)
- **Target file** in the model directory
- **What changes** (math block, prose, or both)
- **StayC update** (if any)
- **Status:** APPLY or DEFERRED (with reason)

Present the full inventory to the human BEFORE proceeding.


STEP 2: PROCESS EACH ITEM
============================

For each non-deferred item in the inventory:

1. Read the llog source section to understand the change
2. Read the target file section to see the current state
3. Verify the old text in the target MATCHES the original
   in the llog. If it doesn't, STOP and FLAG.
4. Propose the EXACT diff (old text → new text)
5. Wait for human approval
6. Apply the change
7. Move to next item

For deferred items: READ the target file and CONFIRM it
matches the pre-change version. Report findings.


STEP 3: CROSS-CUTTING CHECKS
===============================

After processing all items, run these checks:

**Predicate completeness:** Do any applied changes introduce
predicates not yet in ``predicates.rst``? If yes, add them.

**Symbol completeness:** Do any applied changes introduce or
rename symbols? If yes, update ``symbols.rst``.

**Terminology consistency:** Do any changes to one file create
inconsistencies with terminology in other model files?
(E.g., renaming a variable in theorems.rst but not in the
prose of axioms.rst that references it.)

**Scorecard reconciliation:** If the FORGE llog contains a
PP advancement scorecard, compare StayC levels against the
model files. Report discrepancies. Do NOT change StayC
levels without human approval.


STEP 4: POST-REPAIR
======================

1. Run ``make html``. Confirm zero new warnings from model
   files.
2. For each change applied, show the EXACT diff (old → new).
3. Report the complete list of changes made.
4. Report any inconsistencies found (even if resolved).
5. Report any decisions deferred to human.
6. Append the PROMY GROW results to
   ``{{PROMY_LLOG_PATH}}``.
7. Update ``model/{{MODEL_DIR}}/aa.rst`` --- mark resolved
   items, add any new items discovered during GROW.
8. Update ``model/{{MODEL_DIR}}/llog.rst`` with GROW entry.

How to Prepare (Before Running the Prompt)#

  1. Identify all TEMPER rounds. Each round may introduce repairs, fixes, new theorems, or renames. The changes are NOT all in one place — they may be scattered across thousands of lines.

  2. If MODEL_CHANGE markers exist: grep MODEL_CHANGE on the llog and paste the results into the prompt as a pre-built inventory. This saves the AI from scanning.

  3. If no markers exist: You can either:

    1. Let the AI scan (Method B above). This works but is slow and error-prone for large llogs (8000+ lines).

    2. Pre-scan yourself: search for “Repair”, “Fix”, “CHANGE”, “NEW THEOREM” in the llog. Build the inventory by hand and paste it into the prompt. This is what was done for the first e7He GROW run and is more reliable.

    3. Use a two-pass approach: first pass asks the AI to scan and produce ONLY the inventory (no changes). Review the inventory. Second pass gives the AI the verified inventory and asks it to process each item.

  4. Check for variable renames. TEMPER rounds often agree on variable renames that should be applied in math blocks. These are easy to miss because they may be recorded as a discussion rather than a formal repair. Search for “rename”, “BEST Name”, “I-prefix”, or similar.

  5. Check for terminology strengthening. Conceptual changes (like OKO → NOT-OK) may require updating both math blocks AND prose across multiple files.

Common Pitfalls (from e7He GROW)#

  1. Do NOT recommend removing mathematical content to simplify a repair. The e7He GROW initially recommended removing the th3 integral form when applying the conditional strengthening. This was wrong — the integral was the derivation mechanism and the target of a variable rename. Removing it would have destroyed both the proof sketch and the rename. Rule: if content existed for a reason, update it rather than remove it.

  2. Circular reasoning about variable renames. If you recommend removing a math block AND then conclude the rename has “zero targets,” check whether you removed the targets yourself. The rename and the math block may be coupled.

  3. Predicates introduced by repairs. When a repair adds new conditions to a theorem (e.g., adding babl-resisted, rest-adequate, goal-pursued to th3), the new condition predicates need to be added to predicates.rst. FEED audited the ORIGINAL predicates; repairs can introduce new ones that FEED never saw.

  4. Distinguish variable overloading. The same Greek letter may represent different concepts in different contexts (e.g., beta as Iserendipity in the Ie equation vs. beta as bif(h) in bifurcation dynamics). A rename applies to ONE meaning, not all instances of the letter. Read each instance in context.

  5. OKO-type references may be about StayC levels, not the commitment standard. A grep for “OKO” may find both (a) the formal self-assessment variable (should change) and (b) StayC assessment discussions (should NOT change). Read context before applying.