Suggestion: Archive cycle-specific docs after Build and Test approval to prevent stale context on new requirements

[MMVesap]

Summary

When a completed AI-DLC project receives new requirements in a subsequent session, the AI loads all previous artifacts including cycle-specific documents (requirements,
user stories, workflow plans, per-unit functional design). These documents describe intent from the completed cycle — not reality — and can conflict with new
requirements, causing the AI to over-scope or anchor incorrectly on old decisions.

Problem

On session resumption, session-continuity.md instructs the AI to load all previous stage artifacts unconditionally. For a project on its second (or later) cycle this
means:

• Old requirements.md is loaded alongside new requirements → conflation risk
• Old user stories may describe personas or flows that no longer apply
• Old workflow plans describe a scope that is already complete
• Per-unit functional design docs describe the original design intent, not necessarily what the code actually implements

The code itself is the authoritative record of what was built. Old planning documents are one step removed and decay in accuracy over time.

Proposed Solution

Introduce a cycle archive step that executes automatically when the user approves Build and Test results.

Archive step (Build and Test — on approval)

Move cycle-specific documents to aidlc-docs/archive/cycle-N/ (where N increments per cycle):

Source	Destination
inception/requirements/	archive/cycle-N/requirements/
inception/user-stories/	archive/cycle-N/user-stories/
inception/plans/	archive/cycle-N/inception-plans/
construction/plans/	archive/cycle-N/construction-plans/
Per-unit functional-design/ dirs	archive/cycle-N/units/{unit}/functional-design/

Evergreen documents (never archived — stay in place)

• inception/application-design/ — architecture decisions apply to all future cycles
• inception/reverse-engineering/ — still authoritative for brownfield projects
• Per-unit code/ summaries — useful reference for future changes
• construction/build-and-test/ — test baseline history
• aidlc-state.md, audit.md — never archived

Session continuity change

Add a rule to session-continuity.md:

NEVER read files under aidlc-docs/archive/ — archived documents describe intent from a completed cycle and will conflict with new requirements. They are
preserved for audit purposes only.

Split artifact loading into evergreen (always load) and cycle-specific (load only if not yet archived).

Ground truth for new cycles

The current code + aidlc-state.md are the authoritative starting point when cycle-specific artifacts have been archived. Requirements Analysis for the new cycle
starts from a clean slate scoped to the delta.

Benefits

• Prevents stale requirements from polluting new Requirements Analysis
• Keeps the AI context lean — fewer irrelevant documents loaded
• Preserves full history in archive/ for audit and reference (nothing is deleted)
• Makes the "what was intended" vs "what was built" distinction explicit

Files Affected

• aws-aidlc-rule-details/construction/build-and-test.md — add archive step (Step 9) triggered on approval
• aws-aidlc-rule-details/common/session-continuity.md — add archive-skip rule, split evergreen vs cycle-specific loading
• aws-aidlc-rules/core-workflow.md — add archive/cycle-N/ to directory structure reference

[Mameta29]

This resonates strongly with what we hit running AI-DLC end-to-end on a real greenfield project (6 units, full Inception → Construction). By the end, aidlc-docs/construction/ alone held five per-stage directories per unit plus a plans/ directory — a large body of intent documents that a future cycle would load unconditionally per session-continuity.md.

Two observations from that run that support this proposal:

1. The evergreen vs cycle-specific split is the right cut. In our project the per-unit code/ summaries and application-design/ stayed accurate, while the per-unit functional-design/ and nfr-* docs were the most likely to drift from the code once changes landed. The proposed table matches that experience.

2. It composes cleanly with [Bug]: session-continuity.md Per-Unit Design loading is not unit-scoped — resumed sessions cannot locate per-unit artifacts in multi-unit projects #275 / PR fix: scope per-unit artifact loading to unit directories in session-continuity #276. PR fix: scope per-unit artifact loading to unit directories in session-continuity #276 made the Per-Unit Design loading instruction unit-scoped and path-accurate. An archive step is the natural complement: fix: scope per-unit artifact loading to unit directories in session-continuity #276 fixes where to load per-unit artifacts from, and this proposal scopes whether to load them at all on a new cycle. Both touch the same session-continuity.md loading list.

One scope question worth settling before implementation: how should cycle-N be numbered for a project whose first cycle predates this feature — start the existing artifacts at cycle-1 on first archive, or leave them in place and begin numbering at the next cycle? I'd lean toward the former (archive-on-approval always produces cycle-N, N inferred from existing archive/ contents).

If the maintainers are happy with the approach, I'd be glad to open a PR implementing the three file changes listed here. Happy to align on the numbering question and the exact trigger wording first.