@tera-system/core 0.1.0

package/core/tera-system/runtime/TERA_SOLUTION_PREPARATION_TEMPLATES.md

@@ -0,0 +1,397 @@
+# Tera Solution Preparation Templates
+
+هذه القوالب هي مادة دعم تشغيلية رسمية لـ **ApplicationBlueprintAgent (مُهندس)** للمراحل 1–4.
+
+**Reference:** SCP-2026-07-28-118
+**Split from:** `tera-system/runtime/TERA_RUNTIME_TEMPLATES.md`
+**Primary consumer:** مُهندس (ApplicationBlueprintAgent)
+
+---
+
+## 1. Project Decision Template (Phase 2 Output)
+
+الملف: `project-control/TERA_PROJECT_DECISION.md`
+
+```markdown
+# TERA_PROJECT_DECISION.md
+
+> **المرحلة:** 2. Project Decision Formation
+> **أعدّه:** ApplicationBlueprintAgent (مُهندس)
+
+## 1. Decision Metadata
+| البند | القيمة |
+|---|---|
+| اسم المشروع | `[PROJECT_NAME]` |
+| تاريخ القرار | `[DATE]` |
+| حالة القرار | Draft / Pending Approval / Approved / Blocked |
+
+## 2. Intake Readiness
+| البند | الحالة |
+|---|---|
+| Application Idea | Complete / Partial / Missing |
+| Technical Context | Complete / Partial / Missing |
+| Technology Profile Candidate | Found / Missing / Unclear |
+
+## 3. Project Understanding Summary
+[3-5 أسطر]
+
+## 4. Project Type Classification
+| البند | التصنيف |
+|---|---|
+| نوع المشروع | Web App / SaaS / ERP / Mobile / API / MVP / Other |
+| حجم المشروع | Tiny / Small MVP / Medium / Large |
+| مستوى التعقيد | Low / Medium / High |
+
+## 5. Initial Scope Direction
+### داخل النطاق
+- ...
+### خارج النطاق
+- ...
+### مؤجل
+- ...
+
+## 6. Technology Understanding
+| المجال | القيمة | الحالة |
+|---|---|---|
+| لغة البرمجة | ... | ... |
+| Framework | ... | ... |
+| قاعدة البيانات | ... | ... |
+
+## 7. Client Readiness (للمشاريع الخارجية)
+| البند | الحالة |
+|---|---|
+| Client Profile | Complete / N/A |
+| Execution Authorization | Approved / Pending / N/A |
+
+## 8. Required Preparation Files
+| الملف | التصنيف | العميل المتوقع |
+|---|---|---|
+| 01_PROJECT_BRIEF.md | Required | RequirementsScopeAgent |
+| ... | ... | ... |
+
+## 9. Suggested Sub-Agents
+| العميل | الحاجة | السبب |
+|---|---|---|
+| ... | Required / Conditional / Not Needed | ... |
+
+## 10. Initial Risks / Gaps
+| الفجوة | الخطورة | الإجراء |
+|---|---|---|
+
+## 11. Model Tier & Token Policy
+| المرحلة | المستوى الموصى به | السبب |
+|---|---|---|
+| Discovery | Medium | ... |
+| Scope | Medium | ... |
+
+## 12. Tera Decision
+```
+Decision: PROCEED / ASK_MORE / CREATE_PROFILE / STOP
+الخطوة التالية: ...
+```
+
+## 13. Post-Decision Protocol
+1. إنشاء `00_PROJECT_INPUTS.md`
+2. تسجيل في `PROJECT_STATE.md` و `PROJECT_ACTIVITY_LOG.md`
+3. بدء المرحلة 3 — Preparation Planning
+4. لا إنشاء ملفات تحضير قبل اعتماد الخطة
+```
+
+---
+
+## 2. Preparation Plan Template (Phase 3 Output)
+
+الملف: `project-control/PREPARATION_PLAN.md`
+
+```markdown
+# PREPARATION_PLAN.md
+
+## 1. Preparation Decision
+Decision: Proceed / Blocked / Needs More Intake
+Reference: `TERA_PROJECT_DECISION.md`
+
+## 2. Required Preparation Files
+| File | Required | Reason | Owner Agent | Order |
+|---|---|---|---|---|
+| 01_PROJECT_BRIEF.md | Required | Core understanding | RequirementsScopeAgent | 1 |
+| 02_SCOPE_AND_BOUNDARIES.md | Required | Scope discipline | RequirementsScopeAgent | 2 |
+| ... | ... | ... | ... | ... |
+
+Classification Key:
+- Required: Must be created now
+- Conditional: Create only if trigger is met
+- Deferred: Postponed
+- Not Required: Not needed
+
+## 3. Deferred Files
+| File | Reason | Trigger for Activation |
+|---|---|---|
+
+## 4. Not Required Files
+| File | Reason |
+|---|---|
+
+## 5. Suggested Sub-Agents
+| Agent | Needed Now | Reason |
+|---|---|---|
+
+## 6. Preparation Sequence
+```
+Batch A: 01, 08
+Batch B: 02, 04
+Batch C: 05, 07
+Batch D: 06, 09
+```
+
+## 7. User Approval Points
+| Point | What Needs Approval | Before Moving To |
+|---|---|---|
+| P1 | This plan | Phase 4 |
+| P2 | Scope files | Downstream files |
+| P3 | Architecture | Implementation planning |
+
+> Rule: No file creation in Phase 3. No agent generation before plan approval.
+
+## 8. Approval Status
+- [ ] Plan submitted
+- [ ] Plan approved → Phase 4
+```
+
+---
+
+## 3. Agent Delegation Plan Template (Phase 4 Output)
+
+الملف: `project-control/AGENT_DELEGATION_PLAN.md`
+
+```markdown
+# AGENT_DELEGATION_PLAN.md
+
+## 1. Delegation Decision
+Decision: Proceed / Needs User Approval / Blocked
+Reference: `PREPARATION_PLAN.md`
+
+## 2. Agents Needed Now
+| Agent | Reason | Status | Assigned Files |
+|---|---|---|---|
+| RequirementsScopeAgent | Core scope | Generate / Existing / Specialize | 01, 02, 03, 04 |
+
+## 3. Agents Not Needed Now
+| Agent | Reason | Defer Until |
+|---|---|---|
+
+## 4. Agent Generation Actions
+| Agent | Action | Output File | Token Budget |
+|---|---|---|---|
+
+## 5. Delegation Map
+| Preparation File | Assigned Agent | Allowed Sources | Allowed Write Targets |
+|---|---|---|---|
+
+## 6. Activation Plan
+| Agent | Activate Now? | Reason |
+|---|---|---|
+
+## 7. User Approval Points
+| Point | What Needs Approval | Before Moving To |
+|---|---|---|
+| A1 | Agent Generation Plan | Generating agents |
+| A2 | Activating agents | Start delegation |
+
+> Rules: No approved PREPARATION_PLAN.md = No agent generation. No active need = No active sub-agent.
+
+## 8. Approval Status
+- [ ] Plan submitted
+- [ ] Plan approved → Agent generation
+```
+
+---
+
+## 4. Application Discovery Templates
+
+### 4.1 Discovery Notes
+```text
+Application Discovery Notes
+Session date:
+User raw idea summary:
+Normalized application idea:
+Problem / need:
+Target users:
+Main capabilities:
+MVP candidates:
+Later candidates:
+Open questions:
+```
+
+### 4.2 Understanding Summary
+```text
+Application Understanding Summary
+Application name:
+Core idea:
+Problem solved:
+Target users:
+Primary goals:
+Main workflows:
+
+--- Classified Scope ---
+Core MVP (Phase 1A):
+Extended MVP (Phase 1B):
+Phase 2:
+Phase 3:
+Out of scope:
+
+User preferences:
+Technical context:
+Open questions:
+Readiness: Ready / Partially Ready / Not Ready
+```
+
+### 4.3 Discovery Confirmation Request
+```text
+This is my current understanding of the application:
+[summary]
+
+Please confirm:
+1. Approved as basis for project preparation.
+2. Mostly correct, with corrections: ...
+3. Not correct; continue discovery.
+```
+
+### 4.4 Phased Application Roadmap
+```text
+Phase 1 / MVP:
+  Core (Phase 1A):
+  - ...
+  Extended (Phase 1B):
+  - ...
+
+Phase 2:
+- ...
+
+Phase 3:
+- ...
+
+Out of scope:
+- ...
+
+Approval status: Pending / Approved
+```
+
+---
+
+## 5. Engineering Handoff Package Template
+
+الملف: `project-control/ENGINEERING_HANDOFF_PACKAGE.md`
+
+```markdown
+# ENGINEERING_HANDOFF_PACKAGE.md
+
+> **منتج بواسطة:** ApplicationBlueprintAgent (مُهندس)
+> **مستهلك بواسطة:** TeraAgent — Engineering Intake Gate
+> **التاريخ:** YYYY-MM-DD
+> **مصدر التغيير:** SCP-2026-07-28-118
+
+## 1. Workspace and Project Identity
+- **ClientAppPath:** [absolute path]
+- **Project:** [name]
+- **Phase:** Solution Baseline → Engineering Handoff
+
+## 2. Approved Scope / Version References
+- **Scope Source:** [TERA_HANDOFF_PACKAGE.md أو قرار Majed]
+- **Version:** [version]
+- **Approval Date:** [date]
+
+## 3. Preparation Baseline Manifest
+| Document | Lifecycle State | Module Coverage | Notes |
+|---|---|---|---|
+| 01_PROJECT_BRIEF.md | MBA / System Approved | All | |
+| 02_SCOPE_AND_BOUNDARIES.md | MBA | All | |
+| 08_TECHNICAL_ARCHITECTURE.md | System Approved | All | |
+| ... | ... | ... | ... |
+
+## 4. Requirements Traceability Summary
+| Req ID | Source | Workflow | Screen | Data | Acceptance Criteria |
+|---|---|---|---|---|---|
+| ... | ... | ... | ... | ... | ... |
+
+## 5. Architecture / Technology Decisions
+- **Active Technology Profile:** [profile path]
+- **Key Architecture Decisions:**
+  - ...
+- **Constraints:** ...
+
+## 6. Design Source and UI Readiness
+- **Design Source Decision:** [INTERNAL_TERA_KIT / FIGMA / GETDESIGN_MD / HYBRID / NO_UI]
+- **UI Guidance File:** [path to 28_UI_UX_GUIDELINES.md or N/A]
+- **UI Readiness:** Ready / Needs Design / N/A
+
+## 7. Test and Acceptance Readiness
+- **Acceptance Criteria:** Documented / Partial / Pending
+- **QA Plan:** [reference or N/A]
+- **Testability:** All features testable / Partial gaps documented
+
+## 8. Risks, Assumptions, Deferred Items
+| Item | Type | Impact | Mitigation / Notes |
+|---|---|---|---|
+| ... | Risk / Assumption / Deferred | High / Medium / Low | ... |
+
+## 9. Non-Blocking Questions
+| Question | Impact If Unresolved | Suggested Owner |
+|---|---|---|
+| ... | ... | Tera / Majed |
+
+## 10. Recommended Implementation Sequence
+1. [Foundation / Scaffold]
+2. [Database / Core Models]
+3. [Core Workflow / Feature]
+...
+[N]: [Phase 7 — Delivery]
+
+> هذا تسلسل استرشادي. TeraAgent يملك القرار التنفيذي النهائي في Phase 5.
+
+## 11. Solution Readiness Gate Evidence
+- **Gate Result:** PASS
+- **Gate Date:** YYYY-MM-DD
+- **Gate Evidence:** [summary or reference to gate checklist]
+
+## 12. Majed Approval Reference
+- **Approved by:** Majed
+- **Approval Date:** YYYY-MM-DD
+- **Approval Scope:** Full preparation baseline approved for Engineering Intake
+```
+
+---
+
+## 6. Solution Readiness Gate Checklist
+
+```markdown
+# SOLUTION_READINESS_GATE — [Project Name]
+
+## Gate Metadata
+- **Date:** YYYY-MM-DD
+- **Owner:** ApplicationBlueprintAgent (مُهندس)
+
+## Readiness Checks
+| # | Check | Result | Evidence / Notes |
+|---|---|---|---|
+| 1 | Approved commercial/owner source exists | PASS / FAIL | |
+| 2 | Scope/exclusions/deferred/assumptions explicit | PASS / FAIL | |
+| 3 | Every material requirement traced to source | PASS / FAIL | |
+| 4 | Users/roles/workflows/screens/data consistent | PASS / FAIL | |
+| 5 | Error/empty/exception/edge cases covered | PASS / FAIL | |
+| 6 | Security/performance/deployment triggers evaluated | PASS / FAIL | |
+| 7 | UI Design Source Decision exists | PASS / N/A | |
+| 8 | Acceptance criteria observable and testable | PASS / FAIL | |
+| 9 | Required docs reached required lifecycle states | PASS / FAIL | |
+| 10 | Cross-document reconciliation passed | PASS / FAIL | |
+| 11 | No unresolved High/Critical item | PASS / FAIL | |
+| 12 | No Low Confidence section | PASS / FAIL | |
+| 13 | No Pending Approval blocking Phase 5 | PASS / FAIL | |
+| 14 | Technology Profile confirmed | PASS / FAIL | |
+| 15 | Recommended implementation sequence exists | PASS / FAIL | |
+
+## Gate Result
+**PASS / REVISION_REQUIRED / BLOCKED**
+
+## Next Step
+[إذا PASS: "تقديم ENGINEERING_HANDOFF_PACKAGE.md إلى Majed للاعتماد"]
+```

package/core/tera-system/runtime/VERSION_LIFECYCLE_PROTOCOL.md

@@ -0,0 +1,296 @@
+# VERSION_LIFECYCLE_PROTOCOL.md
+
+> **Purpose:** Official Teranoo protocol for application version, release, maintenance, and hotfix lifecycle management.
+> **Layer:** Tera Version Management Layer.
+> **Status:** Active runtime protocol.
+
+---
+
+## 1. Core Rule
+
+```text
+No released version may be modified without opening a Version Cycle, Maintenance Cycle, or Hotfix Cycle.
+```
+
+Arabic operational wording:
+
+> لا يتم تعديل أي نسخة مسلّمة إلا من خلال دورة نسخة جديدة، أو دورة صيانة، أو دورة إصلاح عاجل.
+
+---
+
+## 2. Release Types
+
+| Type | Meaning | Scope Rule |
+|---|---|---|
+| `Initial` | First delivered application version, usually `v1.0` | Uses full 7-phase workflow |
+| `Hotfix` | Urgent production fix after release | No new features allowed |
+| `Patch` | Small bug fixes or safe improvements | No major workflow or module changes |
+| `Minor` | New features within the same product direction | Requires version decision and planning |
+| `Major` | New module, major workflow, breaking change, or new product scope | Requires updated project decision and fuller planning |
+
+---
+
+## 3. Required Project-Control Records
+
+For projects using version management, Tera must maintain:
+
+```text
+project-control/VERSION_REGISTRY.md
+project-control/RELEASE_NOTES.md
+project-control/NEXT_VERSION_HANDOFF.md
+project-control/PROJECT_STATE.md
+project-control/TASK_REGISTRY.md
+project-control/tasks/TASK_TEMPLATE.md
+```
+
+Rules:
+
+- No new version starts without updating `VERSION_REGISTRY.md`.
+- Every task must record `Target Version` and `Release Type`.
+- Every release, patch, or hotfix must update `RELEASE_NOTES.md`.
+- Phase 7 must produce or update `NEXT_VERSION_HANDOFF.md` unless the application reaches Final Application Closure.
+- Deferred features must be linked to a target version or explicitly marked `Unassigned`.
+
+---
+
+## 4. Version Cycle Entry Rules
+
+### 4.0 Version Scope Proposal Ownership
+
+During Phase 2, ApplicationBlueprintAgent (مُهندس — SCP-2026-07-28-118) is responsible for proposing what enters each application version based on:
+
+- Phase 1 discovery information.
+- `MVP_DEFINITION_PROTOCOL.md` classification.
+- Client/user priorities.
+- Risks, dependencies, and implementation complexity.
+- Anti-bloat and smallest useful version rules.
+
+The user/client is responsible for approving, rejecting, or modifying the proposal.
+
+```text
+Client provides needs -> Tera proposes version scope -> User/client approves -> Tera documents and executes.
+```
+
+No version scope becomes official until it is approved and recorded in the relevant project-control records, especially `VERSION_REGISTRY.md` and the Phase 2 decision record.
+
+### 4.0.1 Version Scope Change Requests
+
+If the user/client asks to move a feature, screen, workflow, module, or requirement from one version to another, Tera must classify it as a `Version Scope Change`.
+
+Examples:
+
+```text
+Move Feature X from v1.1 to v1.0.
+Move reports from v2.0 to v1.1.
+Move mobile support out of v1.0 to a later version.
+```
+
+Rules:
+
+- Tera is responsible for updating the version documentation and execution records after approval.
+- If the target version is not released yet, Tera may update that version's approved scope, plans, task registry, and release notes preparation after user/client approval.
+- If the target version is already released, Tera must not rewrite the released version history or tag. Instead, Tera must open the appropriate `Patch`, `Hotfix`, `Minor`, or `Major` cycle.
+- Moving a feature into an earlier unreleased version requires checking MVP impact, schedule impact, risks, dependencies, preparation files, and client approval needs.
+- Moving a feature out of a version requires updating deferred items and the target version in `VERSION_REGISTRY.md`.
+- The original version history must remain traceable.
+
+Required records when applicable:
+
+```text
+VERSION_REGISTRY.md
+PROJECT_STATE.md
+TASK_REGISTRY.md
+RELEASE_NOTES.md
+PROJECT_MASTER_PLAN.md / PROJECT_DETAILED_EXECUTION_PLAN.md
+Phase 2 decision record / VERSION_DECISION.md when used
+```
+
+### 4.1 First Version (`v1.0`)
+
+Default path:
+
+```text
+Phase 1 -> Phase 2 -> Phase 3 -> Phase 4 -> Phase 5 -> Phase 6 -> Phase 7
+```
+
+The first version must define:
+
+- `Current App Version`
+- `Release Type: Initial`
+- Core MVP scope
+- Deferred features and target versions where known
+
+### 4.2 New Minor / Major Version
+
+Before starting `v1.1`, `v2.0`, or later:
+
+1. Read `VERSION_REGISTRY.md`.
+2. Read `NEXT_VERSION_HANDOFF.md` if it exists.
+3. Classify release type: `Minor` or `Major`.
+4. Update or create a version decision record in project-control files.
+5. Update `PROJECT_STATE.md` and `TASK_REGISTRY.md` version fields.
+6. Continue with the smallest sufficient phase path:
+   - Minor: usually Phase 2 update -> Phase 3/5 as needed -> Phase 6 -> Phase 7.
+   - Major: usually updated Phase 2 -> Phase 3 -> Phase 4 if needed -> Phase 5 -> Phase 6 -> Phase 7.
+
+### 4.3 Hotfix / Patch Cycle
+
+Before starting a hotfix or patch:
+
+1. Classify the request as Bug / Hotfix / Patch / Minor Feature / Major Version.
+2. Confirm affected released version.
+3. Confirm no new feature is included in hotfix scope.
+4. Create a versioned fix task using `TASK-COD-FIX-vX.Y.Z-001` or equivalent approved format.
+5. Run Pre-Execution Gate.
+6. Execute in Phase 6.
+7. Run Post-Execution Review.
+8. Update `RELEASE_NOTES.md`, `VERSION_REGISTRY.md`, and `PROJECT_STATE.md`.
+9. Run compact Phase 7 closure for the hotfix/patch.
+
+---
+
+## 5. Versioned TASK-ID Rule
+
+Default versioned format:
+
+```text
+TASK-COD-v1.0-001
+TASK-PREP-v1.0-001
+TASK-REV-v1.0-001
+TASK-COD-FIX-v1.0.1-001
+```
+
+Rules:
+
+- Keep the prefix family (`TASK-COD-*`, `TASK-PREP-*`, `TASK-COD-FIX-*`) compatible with existing Teranoo gates.
+- Do not create duplicate task IDs for the same target version.
+- Read the last used task ID for the target version before creating the next one.
+- `TASK-COD-FIX-*` is for accepted fix work returning from Phase 7 or production maintenance.
+
+---
+
+## 6. Phase 7 Closure Types
+
+Phase 7 must distinguish between:
+
+| Closure Type | Meaning |
+|---|---|
+| `Version Closure` | A delivered version such as `v1.0` is accepted/released |
+| `Maintenance Closure` | Patch or non-urgent maintenance cycle is closed |
+| `Hotfix Closure` | Urgent fix version such as `v1.0.1` is released |
+| `Final Application Closure` | The whole application lifecycle is closed with no planned next version |
+
+Rules:
+
+- Version Closure is not automatically Final Application Closure.
+- No Final Application Closure with hidden open issues or undocumented deferred items.
+- If a next version is likely, update `NEXT_VERSION_HANDOFF.md`.
+
+---
+
+## 7. Git Release Tagging + GitHub Releases Protocol
+
+Git release tagging is the official code-level anchor for a delivered application version. GitHub Releases are the official repository-facing release record when the project remote is hosted on GitHub.
+
+### 7.1 Responsibility Model
+
+| Responsibility | Owner |
+|---|---|
+| Inspecting git status/diff/log before release commit | Tera |
+| Preparing commit message and local commit | Tera |
+| Confirming remote URL from `project-control/GIT_REMOTE.md` | Tera |
+| Asking for push/tag approval | Tera |
+| Approving or rejecting push/tag | User / Majed / authorized client owner |
+| Executing `git push`, `git tag`, and tag push after approval | Tera |
+| Creating GitHub Release after tag push approval | Tera |
+| Recording git/tag result in project-control files | Tera |
+
+User responsibility is approval. Tera responsibility is safe repository handling, release tagging, GitHub Release creation, logging, and version traceability.
+
+### 7.2 Release Tag Preconditions
+
+Before creating a Git release tag:
+
+- Phase 7 Delivery Readiness is `READY` or the closure decision allows release.
+- `VERSION_REGISTRY.md` is updated for the target version.
+- `RELEASE_NOTES.md` contains the target version entry.
+- `PROJECT_CLOSURE_REPORT.md` records Closure Type and Closed Version.
+- No secrets are staged or committed.
+- `project-control/GIT_REMOTE.md` matches the intended repository.
+- User has explicitly approved push/tag action.
+- If GitHub Release is requested, GitHub remote is confirmed and release notes are ready.
+- **CI Status (SCP-2026-07-31-002):** if `.github/workflows/` CI exists for the workspace, the latest run on the release branch should be `PASS` or a documented waiver recorded in `VERSION_REGISTRY.md`. If CI does not exist, record `N/A (no CI)`.
+
+### 7.3 Default Git Release Flow
+
+```text
+review status/diff/log
+-> git add .
+-> git commit -m "Release vX.Y"
+-> ask user approval to push
+-> git push
+-> ask user approval to create/push tag
+-> git tag -a vX.Y -m "Release vX.Y"
+-> git push origin vX.Y
+-> ask user approval to create GitHub Release
+-> gh release create vX.Y --title "Release vX.Y" --notes-file [release-notes-file]
+-> update VERSION_REGISTRY / RELEASE_NOTES / PROJECT_CLOSURE_REPORT / PROJECT_ACTIVITY_LOG
+```
+
+For hotfixes:
+
+```text
+git checkout -b hotfix/vX.Y.Z vX.Y
+```
+
+Only after the user approves the hotfix cycle and Tera confirms the target base tag.
+
+### 7.4 Tag Rules
+
+- Tag names should match the application version: `v1.0`, `v1.0.1`, `v1.1`, `v2.0`.
+- No force-push.
+- No deleting or rewriting release tags without explicit emergency approval.
+- No tag if Phase 7 is blocked.
+- If tag creation is deferred, record why in `VERSION_REGISTRY.md` and `PROJECT_CLOSURE_REPORT.md`.
+- Git tags restore code state, not database state, secrets, uploaded files, or server configuration. Release notes must record migration/deployment notes when relevant.
+
+### 7.5 GitHub Release Rules
+
+- GitHub Release creation is optional per release but recommended for every delivered version after the Git tag is pushed.
+- No GitHub Release without a matching Git tag.
+- No GitHub Release without explicit user approval.
+- GitHub Release notes must come from `project-control/RELEASE_NOTES.md` or a generated release-note excerpt for the target version.
+- If `gh` CLI is unavailable or unauthenticated, record GitHub Release as `Deferred` and keep the Git tag as the source of truth.
+- If the repository is not hosted on GitHub, record GitHub Release as `N/A`.
+- GitHub Releases must not contain secrets, credentials, private environment values, or unapproved client-sensitive information.
+
+---
+
+## 8. Deferred Level 3 Expansion
+
+The following expansion is intentionally deferred until needed:
+
+```text
+project-control/versions/
+/tera-new-version
+/tera-hotfix
+/tera-maintenance
+deprecation / end-of-life workflows
+parallel version support
+```
+
+Activation triggers:
+
+- Large or ERP project.
+- Multiple active versions.
+- Frequent hotfix or maintenance cycles.
+- Need to archive each version separately.
+- Client requires formal version-by-version approval records.
+
+Until then, `VERSION_REGISTRY.md`, `RELEASE_NOTES.md`, `NEXT_VERSION_HANDOFF.md`, and versioned task fields are the official lightweight layer.
+
+---
+
+## 9. Anti-Bloat Rule
+
+Do not create per-version folders or slash commands until the Level 3 activation trigger exists and the user approves it.