PoR Field Usage Census — Agent Prompt for Migration#
Note
Secondary task prompt for migration agents. Embed this prompt’s instructions when an agent is migrating content from OOv1 to OOv2. The agent performs its primary migration task AND simultaneously tracks which PoR fields get populated, which stay empty, and which content wants a field that does not exist.
Prerequisite: The agent must have read CLAUDE.md and the AHA doc (at minimum Sections 1–16, especially Section 9: PoR Fields).
Safety: This prompt asks the agent to APPEND findings to a data collection file. It does not ask the agent to modify the PoR registry or resolve design questions.
Context: The PoR registry (AHA Section 9) defines 40+ fields per element. These were designed analytically — before any real content was migrated into the structure. The OOv1→OOv2 migration is the first empirical test of whether the field set is right-sized. The data collected here will inform Phase 3 decisions about which fields to keep, merge, drop, or add.
/clear /compact
You are performing content migration 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 MIGRATION TASK HERE].
While doing that primary task, you have a secondary task: track PoR field usage for every element you migrate. You are the one touching every piece of content. You are in the best position to see which fields fill naturally and which remain empty.
For each element you migrate, ask yourself these questions:
Which PoR fields does this element’s existing content naturally populate? Look at the current OOv1 source (axioms.rst, theorems.rst, quest.rst). For each field in the PoR registry (Section 9), does the existing content contain material that maps to this field? If yes, status is
Y.Which fields require invention? The content exists in some form but needs restructuring, inference, or expert judgment to fit the field definition. For example: a logic formula buried in prose that needs extraction into FormalNotation. Status is
I.Which fields are empty stubs? No content exists and none can reasonably be inferred. Status is
E.Which fields are not applicable? The field definition does not make sense for this element type. For example: SourceCitation may not apply to a Symbol. Status is
N/A.Does the content want a field that does not exist? This is the most important observation. If you encounter content that clearly belongs in the PoR but does not fit any existing field, record it in the “Proposed New Fields” table. Describe what the content is and why no existing field covers it.
Where to report findings:
Append rows to:
source/matheology/compiler/ee/por-field-usage-census.rst
Use the format documented in that file. One row per field per element. You do not need to record every field for every element — focus on the interesting cases:
Fields that are
Y(confirm the design works)Fields that are
I(reveal hidden content)Fields that are
Econsistently across elements (candidates for dropping or merging)Fields that are
N/Afor entire element types (misfit between field and type)Any proposed new fields (most valuable observation)
Sampling strategy: For the first 3–5 elements you migrate, record ALL fields (complete census). After that, focus on surprises — fields whose status differs from the pattern you saw in the first batch.
At the end of your migration session, write a brief summary (3–5 sentences) at the bottom of the census file, noting: how many elements sampled, how many fields recorded, any patterns (e.g., “all POST fields are consistently empty”, “SourceCitation is Y for axioms but E for theorems”), any proposed new fields, any surprises.
Do not modify the PoR registry. Your job is to collect evidence, not to change the architecture. If you have a strong opinion about a field, state it in the Note column.