Summary

Fixes a reported failure mode where Nelson creates a parallel implementation instead of extending an existing one, even when the Estimate and Battle Plan correctly identify the existing code.

User feedback

"Seems good, tho I tried using this to expand on one feature but it instead create a new feature even though the estimate already correct."

Follow-up clarification:

"I have a feature that kinda doing a 'sync' from google sheets. Save the spreadsheet ID and tab name in environment var. Then I tried to expand this feature by the way of adding more columns to sync. I ran Nelson, the estimate and battle plan already noticed I already have such feature and it will add to it. Implementation done, push, CI/deployment failed. I checked, I found that there are new env for spreadsheet ID and tab name which are blank. Asked Nelson again (in new session), and it says there are two function and one deprecate the other."

Root cause

The Estimate and Battle Plan correctly identified the existing feature, but the implementing captain created a new function with new (blank) env vars instead of modifying the existing one. The information was lost between the Battle Plan and captain execution — not during planning.

Changes

• Crew briefing template (crew-briefing.md): Add standing order telling captains to modify existing implementations in place, not create parallel replacements
• Battle plan template (battle-plan.md): Add "Modification targets" field so the plan specifies exact functions/env vars to modify, not just file ownership
• Drifting anchorage standing order (drifting-anchorage.md): Expand symptoms and remedy to catch parallel-implementation drift
• SKILL.md Step 3: Add scope-preservation paragraph as belt-and-suspenders insurance at the planning layer

Test plan

• Run a mission with Sailing Orders that say "expand feature X" and verify the Battle Plan produces tasks with explicit modification targets
• Verify the crew briefing includes the "do not create parallel implementations" standing order
• Confirm captains receive modification targets in their brief and modify existing code rather than creating replacements
• Verify no regression on missions that genuinely require new files/functions
• Check that the quarterdeck checkpoint catches parallel-implementation drift via expanded drifting-anchorage symptoms