Operating Note — Design After Repair Implementation Rule

Date: 2026-05-11 Source: User instruction during P3D IU/Text-as-Code session Scope: GPT/Opus/Agent workflow for repairs, legacy patches, and post-implementation documentation

Rule

For new systems, continue the proven workflow:

law/requirement → design → prompt → implementation → report/review

For repairs or modifications to older code/systems that lack a clear prior design, use this workflow:

prompt-first execution → implementation report → concise post-implementation design → review/KB archive

Reason

A prompt is an execution instruction. It is useful for getting Agent/Codex/Claude Code to do the work, but it is not sufficient as long-term architecture documentation.

A design is the durable map. Future repair sessions need design documents because understanding the old context usually costs more time than applying the actual patch.

The system will continue to grow and will need many future repairs. Without concise post-implementation designs, future agents will repeatedly rediscover the same context, increasing cost and risk.

When this rule applies

Apply whenever:

• a legacy component is modified;
• the old component lacks a clear design document;
• the repair changes behavior, data flow, safety gates, schema assumptions, or operational workflow;
• the implementation prompt required nontrivial reasoning or multiple revisions;
• the fix becomes production behavior that future agents must understand.

Required post-implementation design

After Agent completes the repair and GPT/User accepts the implementation report, GPT or Opus must create a concise design artifact.

Recommended path pattern:

knowledge/dev/laws/<law-or-pack>/design/<pack>-post-implementation-design-<topic>-<date>.md

Minimum sections:

A. Problem fixed
B. Previous behavior / gap
C. Implemented behavior
D. Authoritative sources / laws complied with
E. Safety gates and rollback
F. Remaining limitations / deferred work
G. Future modification guidance

Assignment rule

GPT should decide who writes it:

• Agent writes it when the repair is mostly technical and the agent has the exact implementation details.
• Opus writes it when architectural interpretation, legal alignment, or council framing is needed.
• GPT may write or patch it directly when the decision needs to be preserved immediately.

Important distinction

Do not replace pre-design with post-design for new systems. New systems still require design before implementation.

Post-implementation design is mainly for legacy/repair work where prompt-first repair was necessary or more efficient.

Dispatch requirement

When GPT approves a repair implementation prompt for Agent, GPT should include a follow-up requirement in the prompt or next directive:

After implementation report is accepted, create a concise post-implementation design so future sessions do not have to reconstruct this repair from prompt/report history.

Status

operating_rule=ACTIVE
applies_to=legacy_repairs_and_patches_without_design
new_systems_still_design_first=true
post_implementation_design_required_after_accepted_repair=true