<stance>
Two files state the same guide and they no longer match. Decide which one is the source, from evidence, not from which one reads better. A derived file often looks more complete, because someone corrected it in place and the correction landed nowhere else. Recency is weak evidence here. Both copies can be stale, in different places, at the same time.
</stance>

<inputs>

1. Ask for the path of every file that carries the same content.
2. Ask which file humans edit day to day.
3. Ask which file the published or rendered output comes from.
4. Ask whether any script or build step already produces one of them.
5. Ask for the last edit time of each file.
Wait for each answer. Do not guess a missing path. Do not proceed on three answers out of five.

</inputs>

<method>

1. List every file. Label each one candidate source or candidate output. State the reason for each label.
2. Diff the files section by section. Record every section that exists in only one file.
3. For each difference, ask which file received the edit first. If nothing settles that, mark the section unresolved.
4. Check what the publishing step reads. A file consumed by a build is a strong candidate for output.
5. Count the sections that exist in one file only. A file holding unique content cannot be regenerated yet.
6. If each file holds unique content, conclude that no single source exists today. Name the merge required before any generator is safe.
7. If the evidence is thin, say which single fact would settle the question. Ask for it.

</method>

<deliver>

- File inventory, with the proposed role of each file.
- Drift table: section, the file that has it, the file that lacks it.
- Unresolved sections, each with the question that would settle it.
- The chosen source, with the reason in one sentence.
- Merge work required before generation can start.

</deliver>

<refuse>

Do not pick a source because it is newer. Do not pick a source because it is longer. Do not call the difference minor. Report every differing section by name. If both files hold content the other lacks, stop. Say that generation would delete work. Name the sections at risk. Do not write the generator in this step. If the user cannot say which file the publishing step reads, say so and stop there.

</refuse>

<stance>
A generated file is only safe when a hand edit cannot survive. Build the one-way path from the source to the secondary format. Conversion is the easy half. The harder half is making the derived file obviously derived, so the next person edits the source instead. Hand-written styling and hand-written sections inside the output are the usual casualties, because regeneration will not carry them.
</stance>

<inputs>

1. Ask for the confirmed source path.
2. Ask which formats the project must publish.
3. Ask where the output is served from or committed to.
4. Ask what the current output contains that the source does not.
5. Ask how the project already runs scripts.
Wait for all five. Do not invent a script runner.

</inputs>

<method>

1. Confirm the source is the file chosen by the earlier audit. Stop if it is not.
2. Inventory everything the output has and the source cannot express. For each item, choose one path. Move it into a template. Move it into the source. Drop it with the user's say-so.
3. Write one script that reads the source and writes the output. Keep it a single command. Allow no manual step between.
4. Add a banner at the top of the output. The banner names the source file. It also names the exact command that regenerates.
5. Run the script. Diff the new output against the committed output.
6. Account for every line of difference before accepting it. An unexplained deletion means the script drops content.
7. If the diff shows losses nobody approved, do not commit. Return to step 2.

</method>

<deliver>

- The generator script.
- The single command that runs it.
- The banner text placed in the output.
- The template or style file holding presentation.
- The diff review, line by line.
- Content dropped, with who approved each drop.

</deliver>

<refuse>

Do not hand-edit the output to shrink the diff. Do not claim the formats match without diffing them. Do not delete the previous output before the diff is reviewed. Do not add a dependency the project does not already use unless the user agrees. If the source cannot express something the output needs, stop. Name that content. Ask where it should live. Do not silently drop it and report success.

</refuse>

<stance>
The generator exists and the two files match today. That says nothing about next month. Design the check that fails when someone edits the output by hand. Design it to fail when someone edits the source and forgets to regenerate. A check that runs only when a person remembers is not a check.
</stance>

<inputs>

1. Ask for the command that regenerates the output.
2. Ask for the output path.
3. Ask what runs automatically on every change.
4. Ask whether the output is committed or built on publish.
Wait for each answer. Do not assume a check runner exists.

</inputs>

<method>

1. Regenerate into a scratch location. Diff against the committed output. A clean diff means the committed output is current.
2. Change one line in the source. Regenerate. Confirm the diff shows that line. If it does not, the generator ignores part of the source.
3. Revert the source change. Regenerate. Confirm the output returns to its committed state.
4. Edit one line of the output by hand. Regenerate. Confirm the hand edit disappears. That disappearance is the whole reason nobody may edit the output directly.
5. Wire step 1 into the automatic check. Make a non-empty diff fail the run.
6. If the project has no automatic check, write the one command and name where it must be called from. State plainly that an unwired check will drift.
7. Record which of the four tests passed. A test that did not run is not a pass.

</method>

<deliver>

- Result of each of the four tests, pass or fail.
- The exact diff output from the source-edit test.
- The check wiring, with the file it lives in.
- Remaining gaps, named.

</deliver>

<refuse>

Do not report the check as working without running it. Do not mark a test passed from reading the script. If the hand edit survives regeneration, stop. Say the output is still writable and the drift remains possible. If step 2 produces no diff, stop. The generator is not reading the section you changed. Do not describe a check as automatic when a person must remember to run it.

</refuse>