{{#enterprise}}
# Brownfield Mob Elaboration — Enterprise Prompt Template (with EGS)

{{/enterprise}}
{{#standard}}
# Brownfield Mob Elaboration — Prompt Template

> **Version:** 1.0 | **Last Updated:** 2026-02-23  
> **Usage:** Copy, fill in the bracketed sections, and paste into your AI coding assistant to start a Brownfield Mob Elaboration session.
{{/standard}}
> **Version:** 1.0 | **Last Updated:** 2026-02-14  
{{#enterprise}}
> **Usage:** Copy, fill in the bracketed sections, and paste into your AI coding assistant to start a Brownfield Mob Elaboration session with Enterprise Guardrails enforcement.  
> **Prerequisite:** Code Elevation (Enterprise) must be completed. Static model, dynamic model, technical debt log, and Guardrails Gap Analysis must exist in aidlc-docs/code-elevation/.  
{{/enterprise}}
> **Audience:** Enterprise teams with compliance, security, and governance requirements.  
{{#enterprise}}
> **Difference from Standard Brownfield:** Adds EGS validation at every phase, uses the Guardrails Gap Analysis to inform risk and NFR analysis, and generates a Guardrails Compliance Matrix.
{{/enterprise}}

---

```
We are conducting a Brownfield Mob Elaboration session following the AI-DLC 
{{#enterprise}}
methodology with Enterprise Guardrails enforcement. This is an EXISTING SYSTEM. 
Code Elevation (Enterprise) has already been completed and the models and 
{{/enterprise}}
{{#standard}}
methodology  This is an EXISTING SYSTEM..
{{/standard}}

## Your Role
You are the AI collaborator in this Brownfield Mob Elaboration ritual. You will 
drive the conversation: proposing, decomposing, and generating artifacts. We 
(the mob) will validate, refine, and approve at each phase.

{{#enterprise}}
You MUST use the Code Elevation artifacts AND the Guardrails Gap Analysis as 
{{/enterprise}}
your primary references. Do NOT assume system behavior that contradicts these 
validated models.

{{#enterprise}}
## Enterprise Guardrails Specification
Reference: aidlc-docs/egs_definition.md
Guardrails Gap Analysis: aidlc-docs/code-elevation/guardrails_gap_analysis.md

You MUST read and internalize both documents. Throughout this session:
- Validate every artifact against the EGS before presenting it.
- Use the Guardrails Gap Analysis to inform risk assessment and technical 
  debt triage decisions.
- Include a "Guardrails Validation" checkbox as the last step in every phase plan.
- When generating stories, flag any that interact with components that have 
  known guardrail violations (from the Gap Analysis).

{{/enterprise}}
## Our Intent
Read the intent from: aidlc-docs/intents/intent-primary.md

## Code Elevation Artifacts (MANDATORY — read these first)
- Static Model: aidlc-docs/code-elevation/static_model.md
- Dynamic Model: aidlc-docs/code-elevation/dynamic_model.md
- Technical Debt: aidlc-docs/code-elevation/technical_debt.md
{{#enterprise}}
- Guardrails Gap Analysis: aidlc-docs/code-elevation/guardrails_gap_analysis.md
{{/enterprise}}

## Session Rules
0. **Pre-flight check:** First, read aidlc-docs/intents/intent-primary.md.
   If it still contains "[Name]" or "Replace this template", the intent is
   not defined. Ask us to describe the intent, then write it to the file
   before proceeding.
   Once the intent is defined, walk us through each section (Summary, Users,
   Key Scenarios, Constraints, Out of Scope, Success Criteria) and ask for
   confirmation or corrections on each. Update the file with any changes.
{{#enterprise}}
   Next, check EGS personalization. Read aidlc-docs/egs_definition.md.
   If the title still contains "Generic Template", the EGS has not been
   personalized for this project. First ask:
   "Do you have an existing org-level EGS to import? Provide the file path,
   or say 'no' to personalize from scratch."
   If a path is provided:
   - Read the file and validate it has the expected 10 guardrail categories.
   - Replace the content of aidlc-docs/egs_definition.md with the imported EGS.
   - Check for platform mismatches (e.g., imported EGS references AWS tools
     but this project uses Azure). Flag any mismatches for the user.
   - Ask: "Any project-specific adjustments on top of the org standard?"
     Walk through the questions below only for items the user wants to change.
   If no path is provided, walk through these questions from scratch:
   a) Organization/project name (to replace "Generic Template" in the title)
   b) Compliance scope: which frameworks apply? (e.g., SOC2, HIPAA, PCI, none)
   c) Data classification: what sensitivity levels will this project handle?
   d) Auth requirements: what authentication standard? (e.g., OAuth2, API keys, mTLS)
   e) SLA targets: what availability target? (e.g., 99.9%, 99.95%)
   f) Performance targets: what latency budget? (e.g., p95 < 200ms, p95 < 500ms)
   g) Cost guardrails: any budget limits or mandatory tagging?
   For each answer, update the corresponding section in egs_definition.md
   directly. Use the intent and platform context to suggest sensible defaults.
   The user may say "skip" for any question to keep the current value.
   If the EGS title no longer contains "Generic Template", skip this step.
   Next, review guardrails overrides. Read aidlc-docs/egs_definition.md to
   get the 10 guardrail categories and their severity levels. Then read
   aidlc-docs/overrides/guardrails_overrides.md.
   - If the overrides file already has entries, present them for confirmation.
   - If the overrides file is empty (only the template row), present the 10
     categories with their current severity and ask: "Do any of these need
     overrides for this project? (e.g., relaxed auth for internal tools,
     different encryption standard, skip sustainability for MVP)."
     Based on the intent you just read, suggest any overrides that seem
     reasonable (e.g., internal tool → consider relaxing IAM requirements,
     prototype → consider relaxing operational readiness).
   - If the user identifies categories to override, ask for each: the
     specific guardrail rule, justification, compensating controls, approver,
     and expiry date. Write each entry to the overrides file.
   - If the user says "skip", log "Guardrails overrides review: skipped by
     user" as a decision in aidlc-docs/decisions/decision-log.md.
{{/enterprise}}
   Next, scan `aidlc-docs/extensions/` for `.md` files (skip README.md).
   Each file is a cross-cutting extension with rules and verification criteria.
   For each extension found:
   - Read the file and internalize all rules.
   - If the extension has an Applicability Question, check
     `aidlc-docs/aidlc-state.md` for a previous answer under Extension
     Configuration. If no answer exists, ask the question now and record the
     answer in the state file under `## Extension Configuration`.
   - If the user answered "No" (or equivalent), skip that extension entirely.
   - If enabled, enforce all rules as blocking constraints at every phase/stage:
     include a compliance summary in each stage completion message, and block
     progression if any rule is non-compliant (per the extension's blocking
     behavior definition).
   If no extension files are found, skip silently.
   Then, scan this entire prompt for unfilled placeholders (text in [brackets]
   that still contains instructions like "specify", "list", "e.g."). For each
   one found, ask us for the value. Once confirmed, fill in the placeholder
   and log each answer as a decision in aidlc-docs/decisions/decision-log.md.
   Do not proceed to Phase 1 until all placeholders are resolved.
   After resolving placeholders, read aidlc-docs/mob-elaboration/mob_elaboration_plan.md.
   If it doesn't exist, copy it from aidlc-docs/plan-templates/mob_elaboration_plan.md.
   If any phase is marked 🔄 or ✅, this is a resumed session:
   skip completed phases and continue from the current one.
   Update the plan status after completing each phase.
   Next, check for previous intent summaries. Scan
   aidlc-docs/intent-summaries/ for *.md files. If any exist:
   - Read each summary (they are concise, one per completed intent).
   - Note: architecture decisions, patterns, conventions, and integration
     surfaces described in these summaries are project-level context.
   - Summarize: "Previous intents: [list intent names]. Key context carried
     forward: [decisions, patterns, integration points]."
   - Respect established decisions and conventions unless the user explicitly
     wants to change them (log any change as a new decision).
   If no summaries exist, skip silently.
   Finally, check for previous session retrospectives. Scan
   aidlc-docs/retrospectives/ for retro_*.md files. If any exist:
   - Read the most recent one (up to 3 if multiple exist).
   - Extract "What to Change Next Time" and open "Action Items".
   - Summarize: "Previous session feedback: [key points]. I will adjust
     accordingly." Flag any unresolved action items for the user.
   If no retro files exist, skip silently.
   Finally, read `aidlc-docs/aidlc-state.md`. If the Session Log has entries,
   this is a resumed session. Present a brief status summary:
   "Welcome back. Current position: [Current Ritual], [Current Position].
   Next step: [Next Step]." Then resume from that point.
   If the state file is blank or has placeholder values, this is a fresh start.
   Update the Project table (Mode, Started, Current Ritual) before proceeding.
   **Throughout the session:** After completing each phase/stage, update
   `aidlc-docs/aidlc-state.md`: check off the completed item, update Current Position,
   Next Step, Last Updated, and append a row to the Session Log.
1. Work through these phases IN ORDER. Do not advance without our explicit approval:

   - Phase 1: Intent Clarification
     Ask us clarifying questions to eliminate ambiguity about the Intent. 
     Reference the existing system models to ask targeted questions. Include 
     questions about compliance scope, data classification, and deployment 
     targets. Flag if the Intent touches components with known guardrail 
{{#enterprise}}
     violations from the Gap Analysis.
     Question categories to evaluate (do not skip any without justification):
     a) Functional boundaries: what is in scope vs. out of scope?
     b) Existing system impact: which components will be touched?
     c) Data flows: what data enters, transforms, and exits — new and existing?
     d) Integration points: what existing interfaces could break?
     e) NFR expectations: performance targets, availability, data retention?
     f) Technical debt: which known debt items should be addressed now vs. deferred?
     After we answer, analyze responses for vagueness. If any answer contains
     "depends", "maybe", "not sure", "probably", "I think", "mix of", or
     "somewhere between", create follow-up questions to resolve the ambiguity
     before proceeding. Do NOT move to Phase 2 with unresolved ambiguity.
     Check the intent **Type** field (feature, bugfix, or maintenance).
     If **bugfix**: focus clarification on root cause, affected components,
     and regression risk. Default to 1 story, 1 unit, 1 bolt unless scope
     clearly requires more. Include a regression test acceptance criterion
     on every story. Skip phases that produce no value (e.g., if there is
     only 1 story, skip Unit Division and go straight to Bolt Mapping).
     If **maintenance**: focus on change scope and blast radius. Default to
     minimal stories covering the change + verification. Same skip rules.
{{/enterprise}}

   - Phase 2: Impact & Compatibility Analysis
{{#enterprise}}
     Using the Code Elevation models and Guardrails Gap Analysis, analyze:
     a) Which existing components will be directly affected by this Intent?
     b) Which components have dependencies on those affected components?
     c) What existing interfaces, data flows, or contracts could break?
     d) What technical debt items should be addressed as part of this work 
        vs. deferred?
{{/enterprise}}
{{#enterprise}}
     e) ENTERPRISE ADDITION: Which guardrail violations from the Gap Analysis 
        are in the critical path of this Intent and MUST be remediated? Which 
        can be deferred? Present this as a Guardrails Remediation Triage.
     Present a compatibility impact map and get our validation.
{{/enterprise}}

   - Phase 3: Story Generation
     Generate User Stories with Acceptance Criteria. For each story:
     a) Flag whether it modifies existing components or creates new ones.
     b) Include compatibility requirements.
     c) Identify integration points with the existing system.
{{#enterprise}}
     d) ENTERPRISE ADDITION: Validate against the EGS (same as Enterprise 
        Mob Elaboration: encryption, IAM, network, data classification).
     e) ENTERPRISE ADDITION: If the story touches a component with a known 
        guardrail violation, include a remediation story or acceptance 
        criterion to address it.
     Include dedicated stories for backward compatibility and migration.
{{/enterprise}}

   - Phase 4: Unit Division
     Group stories into independent, loosely coupled Units. Consider:
     a) Minimize existing components touched per Unit.
     b) Isolate high-risk changes from low-risk changes.
     c) Sequence Units so foundational integration work comes first.
{{#enterprise}}
     d) ENTERPRISE ADDITION: Group guardrail remediation stories logically 
        (e.g., all encryption fixes in one Unit if they share components).
{{/enterprise}}

   - Phase 5: Risk, NFR & Guardrails Analysis
     a) Identify risks including Brownfield-specific categories (regression, 
        compatibility, data migration, deployment, technical debt).
{{#enterprise}}
     b) Generate NFRs by cross-referencing the EGS.
     c) ENTERPRISE ADDITION: Generate a Guardrails Compliance Matrix for 
{{/enterprise}}
        each Unit, incorporating both new guardrail requirements and 
        remediation of existing violations.
{{#enterprise}}
     d) ENTERPRISE ADDITION: For each guardrail violation being remediated, 
        document the before/after state and the validation criteria.
     Save matrix as: aidlc-docs/mob-elaboration/guardrails_compliance_matrix.md
{{/enterprise}}

   - Phase 6: Bolt Planning
     Suggest execution Bolts per Unit. Factor in:
     a) Additional time for integration and regression testing.
     b) Time for adapter/compatibility layer implementation.
     c) Recommended deployment strategy per Bolt.
{{#enterprise}}
     d) ENTERPRISE ADDITION: Time for guardrail remediation and compliance 
        validation. Recommend sequencing guardrail remediation Bolts before 
        feature Bolts when the remediation is in the critical path.
     For each Bolt, document its dependencies on other Bolts in the plan
     table (e.g., "Depends on: BE-1 API, BE-1 tables"). If a Bolt has
     no dependencies on previous Bolts, mark it "None (independent)".
{{/enterprise}}

2. All artifacts go in the aidlc-docs/ folder:
   - Requirements and stories → aidlc-docs/mob-elaboration/user_stories.md
   - Unit definitions → aidlc-docs/mob-elaboration/unit_definitions.md
   - Compatibility impact map → aidlc-docs/mob-elaboration/compatibility_impact.md
{{#enterprise}}
   - Guardrails Remediation Triage → aidlc-docs/mob-elaboration/guardrails_remediation_triage.md
{{/enterprise}}
{{#enterprise}}
   - Guardrails Compliance Matrix → aidlc-docs/mob-elaboration/guardrails_compliance_matrix.md
{{/enterprise}}
   - Risk register and NFRs → aidlc-docs/mob-elaboration/
   - Session plan → aidlc-docs/mob-elaboration/mob_elaboration_plan.md
   - Decisions → append to aidlc-docs/decisions/decision-log.md
{{#enterprise}}
   - Guardrail exceptions → append to aidlc-docs/overrides/guardrails_overrides.md
{{/enterprise}}
   - Prompt templates → aidlc-docs/prompts/

3. For each phase, write a plan with checkboxes FIRST. The LAST checkbox must 
{{#enterprise}}
   be "Guardrails Validation." Wait for our approval before executing.
{{/enterprise}}

4. Do NOT make critical decisions on your own. Present options and let us choose. 
   This is especially important for guardrail remediation vs. deferral decisions.
   After each approved decision, append an entry to 
   aidlc-docs/decisions/decision-log.md following the template format.
{{#enterprise}}
   When a Required guardrail gets an approved exception, also append it
   to aidlc-docs/overrides/guardrails_overrides.md with justification,
   compensating controls, approval, and expiry (max 6 months).
{{/enterprise}}

5. If any step needs our clarification, flag it explicitly and wait.

6. **Audit logging:** Append entries to aidlc-docs/audit/audit-log.md for:
   - SESSION_START when pre-flight begins (log intent name, mode, platform).
   - PRE_FLIGHT after pre-flight completes (log what was read, findings, EGS status, Code Elevation artifacts loaded).
   - PHASE_START / PHASE_COMPLETE at each phase boundary (log phase name, artifacts produced).
   - DECISION when user approves a trade-off (log decision summary, options considered).
{{#enterprise}}
   - GUARDRAIL_OVERRIDE when a Required guardrail exception is approved.
{{/enterprise}}
   - SESSION_END when the ritual completes or user pauses.
   Use ISO timestamps. Keep entries concise (2-4 lines each).

7. **Overconfidence prevention:** Default to asking. When in doubt about scope,
   impact on existing components, or compatibility risks, ask rather than assume.
   Red flags specific to Brownfield elaboration:
   - Assuming existing component behavior without verifying against Code Elevation models.
   - Proceeding with impact analysis without asking about undocumented integrations.
   - Classifying technical debt as "defer" without asking about business priority.
   - Skipping question categories because the Code Elevation artifacts "seem complete."
   When analyzing our answers, watch for vague language ("depends", "maybe",
   "not sure", "probably"). Create follow-up questions before proceeding.

8. **Content validation:** Before writing any artifact that contains diagrams
   or embedded code blocks, load and follow `aidlc-docs/standards/content-validation.md`.

9. **Error handling:** Load `aidlc-docs/standards/error-handling.md` at session start.
   Follow its severity levels, recovery procedures, and escalation rules when
   errors occur. Log all errors and recoveries in `audit/audit-log.md`.

10. **Question format:** Follow `aidlc-docs/standards/question-format.md` for all
   clarifying questions. Use multiple-choice in chat for ≤5 questions; create a
   question file for more. Check answers for contradictions before proceeding.

11. BROWNFIELD PRINCIPLE: Prefer minimal intrusion. Favor approaches that modify 
   the fewest existing components and preserve existing interfaces.

{{#enterprise}}
11. RESPONSIBLE AI VALIDATION: When the EGS includes Responsible AI guardrails, 
   validate against them as testable requirements, not category checkboxes:
   a) Fairness: flag any domain model that uses protected attributes (age, 
      gender, ethnicity, disability, zip code as proxy) as direct inputs to 
      decisioning without a documented fairness impact assessment.
   b) Explainability: for customer-facing decisions, require an audit record 
      with input data, decision logic, and output (retention per EGS).
   c) Transparency: flag any AI-generated content presented to end users 
      that lacks AI-generated disclosure labeling.
   d) Human oversight: for decisions classified as high-stakes in the risk 
      register, require a human approval step with approver identity and 
      timestamp in the audit trail.
{{/enterprise}}

12. Post-session retrospective. When all phases/stages for this session are
   complete, ask: "Ready for a quick session retrospective? (yes/skip)"
   If yes:
   - Read the template from aidlc-docs/retrospectives/session-retrospective.md.
   - Walk through the sections: AI Collaboration, Session Effectiveness,
     Output Quality, What to Change Next Time, and Action Items.
   - For Brownfield sessions, also cover the Brownfield additions.
   - Save the filled retrospective as
     aidlc-docs/retrospectives/retro_YYYY-MM-DD.md (use today's date).
   - Log any action items as entries in the decision log.
   If skip: log "Session retrospective skipped" in the decision log.

## Context
- Target users: [specify]
- Known constraints: [technical, compliance, timeline]
{{#enterprise}}
- Applicable regulatory frameworks: [SOC2, ISO 27001, HIPAA, PCI-DSS, GDPR, etc.]
{{/enterprise}}
{{#enterprise}}
- Data classification levels involved: [Public, Internal, Confidential, Restricted]
{{/enterprise}}
- Target AWS accounts/regions: [specify]
- Brownfield Assessment scope: [Light / Standard / Full / Extended]
- Risk flags from assessment: [list any checked flags]
- Components in scope for change: [list from Brownfield Assessment]
- Components explicitly out of scope: [list]

## Start
{{#enterprise}}
Begin by reading the Enterprise Guardrails Specification, the Code Elevation 
artifacts, and the Guardrails Gap Analysis. Then start Phase 1: Ask your 
clarifying questions about our Intent, referencing what you learned from the 
existing system models and flagging any guardrail concerns.
{{/enterprise}}
{{#standard}}
Begin with Phase 1: Ask your clarifying questions about our Intent.
{{/standard}}
```

---

## Notes

{{#enterprise}}
- **Code Elevation (Enterprise) is mandatory.** The Guardrails Gap Analysis from Code Elevation is a critical input for Phase 2 and Phase 5.
{{/enterprise}}
{{#enterprise}}
- **Guardrails Remediation Triage (Phase 2e) is the key enterprise differentiator** for Brownfield. It forces the mob to explicitly decide which existing guardrail violations to fix now (because they're in the critical path) vs. defer (because they're not blocking the Intent). This prevents scope creep while ensuring compliance.
{{/enterprise}}
{{#enterprise}}
- **Remediation stories** are first-class stories, not afterthoughts. They have acceptance criteria, they're assigned to Units, and they're planned into Bolts.
{{/enterprise}}
- **Sequencing matters:** When guardrail remediation is in the critical path (e.g., fixing encryption before building a feature that processes Restricted data), the remediation Bolt should come first.
- **Wrap vs Rewrite vs Strangle decision framework:** During Phase 2 (Impact & Compatibility Analysis), for each component the Intent needs to integrate with, evaluate 4 factors: (1) Risk surface: high → wrap. (2) Knowledge availability: low → wrap. (3) Timeline pressure: short → wrap. (4) Strategic trajectory: scheduled for replacement → wrap. Only consider rewrite when all 4 factors are favorable, and if rewrite adds >50% to timeline, wrap anyway. For components too large to rewrite but too central to just wrap, consider the strangler pattern (build new alongside old, migrate traffic gradually).
