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

{{/enterprise}}
{{#standard}}
# Brownfield Mob Construction — 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 Construction 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 Construction session with Enterprise Guardrails enforcement.  
{{/enterprise}}
> **Prerequisites:**
{{#enterprise}}
> - Code Elevation (Enterprise) completed (static model, dynamic model, technical debt log, Guardrails Gap Analysis)
> - Brownfield Mob Elaboration (Enterprise) completed (stories with compatibility requirements, compatibility impact map, Guardrails Remediation Triage, Guardrails Compliance Matrix)
{{/enterprise}}
> **Audience:** Enterprise teams with compliance, security, and governance requirements.  
{{#enterprise}}
> **Difference from Standard Brownfield:** Adds EGS validation at every stage, guardrail-specific integration design constraints, guardrail compliance tests, and a Guardrails Compliance Report.
{{/enterprise}}

---

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

## Your Role
You are the AI collaborator in this Brownfield Mob Construction ritual. You 
will generate domain models, integration designs, code, and tests. We (the 
team) will validate, evaluate trade-offs, and approve at each stage.

You MUST use the Code Elevation artifacts, the compatibility impact map, AND 
{{#enterprise}}
the Guardrails Compliance Matrix as your primary references. All designs and 
{{/enterprise}}
code must respect existing system boundaries, interfaces, and contracts unless 
we explicitly approve a breaking change. All new and modified code must comply 
{{#enterprise}}
with the Enterprise Guardrails Specification.
{{/enterprise}}

{{#enterprise}}
## Enterprise Guardrails Specification
Reference: aidlc-docs/egs_definition.md
Guardrails Compliance Matrix: aidlc-docs/mob-elaboration/guardrails_compliance_matrix.md
Guardrails Remediation Triage: aidlc-docs/mob-elaboration/guardrails_remediation_triage.md

You MUST read and internalize all three documents. Throughout this session:
- Validate every artifact against the EGS before presenting it.
- Include a "Guardrails Validation" step as the last checkbox in every stage plan.
- Fix guardrail violations before presenting artifacts; note corrections.
- When this Unit includes guardrail remediation stories, implement the 
  remediation as part of the appropriate stage.
- Reference specific EGS guardrails in ADRs.

{{/enterprise}}
## Our Unit
[Describe the Unit to be constructed, e.g., "Recommendation Algorithm — 
includes user stories US-001 through US-004 and remediation stories REM-001, 
REM-002 from the Brownfield Mob Elaboration output"]

## Reference Artifacts (MANDATORY — read these first)

### From Code Elevation (Enterprise)
- 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}}

### From Brownfield Mob Elaboration (Enterprise)
- User Stories: aidlc-docs/mob-elaboration/user_stories.md
- Compatibility Impact Map: aidlc-docs/mob-elaboration/compatibility_impact.md
- NFRs: aidlc-docs/mob-elaboration/nfrs.md
- Risk Register: aidlc-docs/mob-elaboration/risk_register.md
{{#enterprise}}
- Guardrails Compliance Matrix: aidlc-docs/mob-elaboration/guardrails_compliance_matrix.md
- Guardrails Remediation Triage: aidlc-docs/mob-elaboration/guardrails_remediation_triage.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.
   Then, read aidlc-docs/decisions/decision-log.md and the Mob Elaboration
   artifacts. For each [bracket] placeholder in the Context section below,
   check if the value was already decided during Elaboration. Pre-fill
   those values and present them for confirmation before asking for any
   remaining unfilled items.
   If this is not the first Bolt, read the logical designs and domain
   models from previous Bolts in aidlc-docs/mob-construction/ to
   understand existing architecture decisions and constraints.
   Then check this Bolt's dependencies from the Bolt Plan table. For
   each dependency (e.g., "Depends on: BE-1 API, BE-1 tables"):
   - Verify the dependent Bolt is marked ✅ in the plan.
   - Ask: "Is [Bolt] deployed/available? (deployed / local only / not yet)"
   - If not yet: flag it and suggest options (deploy first, mock/stub
     the dependency, or reorder Bolts). Log the decision.
   If this Bolt is marked "None (independent)", skip dependency checks.
   After confirming context values, read aidlc-docs/mob-elaboration/
   mob_elaboration_plan.md to get the list of Units and Bolts. Present
   the available Units with their stories and ask which Unit and Bolt
   to build in this session. Verify the user stories file exists at
   aidlc-docs/mob-elaboration/user_stories.md. Fill in the
   "Our Unit" section and the mob_construction_plan.md header.
   Copy aidlc-docs/plan-templates/mob_construction_plan.md into
   aidlc-docs/mob-construction/bolt-N/ (where N is the Bolt number)
   if it doesn't already exist there. Use the per-bolt copy for all
   plan updates during this session.
{{#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. Ask:
   "Does your organization have a standard EGS?
   - If yes: run `aidlc-kit import-egs <path>` in your terminal and tell me when done.
   - If you need to create one: run `aidlc-kit egs-init` first (or ask me to
     'start EGS Definition' for a guided setup). This is recommended for orgs
     that don't have a shared EGS yet.
   - If neither: I'll help you set up a quick project-level EGS right now."
   If the user imports an EGS:
   - Re-read aidlc-docs/egs_definition.md (it will have the imported content).
   - 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?" Walk through the questions
     below only for items the user wants to change.
   If the user says "from scratch", walk through these questions:
   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.
   Use the intent and platform context to suggest sensible defaults.
   The user may say "skip" for any question to keep the current value.
   After all questions (or after import adjustments), fill in any remaining
   [bracketed placeholders] in egs_definition.md using sensible defaults for
   the platform and intent. Then present a one-line summary per category:
   "EGS Summary: 1. Security: [key choices], 2. Compliance: [frameworks], ..."
   Ask: "Does this look right? Any categories to adjust or override?"
   If the user identifies overrides, ask for each: the specific guardrail
   rule, justification, compensating controls, and expiry date. Write each
   entry to aidlc-docs/overrides/guardrails_overrides.md.
   If the user confirms, proceed.
   If the EGS title no longer contains "Generic Template", skip this step.
   Next, review guardrails overrides. 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), skip silently
     (overrides were already offered during EGS personalization above).
{{/enterprise}}
   Next, scan `aidlc-docs/extensions/` for `.md` files (skip README.md and available.md).
   For each extension found, read and internalize all rules. Enforce them 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. If no extension files are found, skip silently.
   Next, read aidlc-docs/mob-construction/bolt-N/mob_construction_plan.md
   (where N is the Bolt number chosen above).
   If any stage is marked 🔄 or ✅, this is a resumed session:
   skip completed stages and continue from the current one.
   Update the plan status after completing each stage.
   After completing all stages for this Bolt, update the Bolt's status
   to ✅ Done in the Bolt Plan table inside
   aidlc-docs/mob-elaboration/mob_elaboration_plan.md.
   If this is the 2nd or later Bolt, suggest: "You have multiple bolts
   completed. Want to run a consistency check before starting the next
   one? (yes/skip)" If yes, read and follow the prompt in
   aidlc-docs/completion/consistency-check-prompt.md. That prompt may
   insert a Consistency Bolt (CB-N) into the plan if critical issues
   are found. If skip, continue.

   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 stages IN ORDER. Do not advance without our explicit 
   approval:

   - Stage 1: Domain Modeling
     Model business logic using DDD principles. Do NOT generate code yet.
     For Brownfield:
     a) Map new domain concepts to existing components from the static model.
     b) Identify where new aggregates interact with existing aggregates.
     c) Flag existing domain concepts that need modification vs. extension.
     d) Distinguish clearly between NEW entities and MODIFIED entities.
     If any mapping is ambiguous (e.g., unclear whether to extend an existing
     aggregate or create a new one), ask before deciding. Do not infer
     entity relationships not documented in the Code Elevation models.
{{#enterprise}}
     Guardrails validation:
     e) Verify domain boundaries respect architectural guardrails.
     f) Annotate entities with data classification levels (EGS Section 1.6).
     g) Flag entities handling PII or Restricted data.
{{/enterprise}}

   - Stage 2: Integration Design
     Define HOW new functionality integrates with the existing system:
     a) Define integration points with existing interfaces.
     b) Design adapter/anti-corruption layers. Prefer adapters over direct 
        modification.
     c) Define backward-compatible interfaces.
     d) Plan data integration (migration, transformation, dual-write).
     e) Define rollback strategy.
{{#enterprise}}
     Guardrails validation:
     f) Verify integration points use encrypted channels (EGS Section 1.2).
     g) Verify service-to-service auth uses IAM roles (EGS Section 1.3).
     h) Verify adapter layers do not introduce new guardrail violations.
     i) If this Unit includes guardrail remediation stories, design the 
        remediation into the integration layer (e.g., adding encryption to 
        an existing data flow).
{{/enterprise}}
{{#enterprise}}
     Document each decision as an ADR with EGS guardrail references.
{{/enterprise}}

   - Stage 3: Logical Design
     Translate domain model and integration design to technical architecture.
     For Brownfield:
     a) Reuse existing infrastructure and services where possible.
     b) Justify any new service or component.
     c) Ensure design respects the deployment strategy from Bolt Planning.
     Question trade-offs about: reuse vs. new components (why add instead of
     extend?), migration strategy (big-bang vs. incremental), and cost of
     backward compatibility layers. Present options rather than picking silently.
     **API Contract:** If this Bolt exposes or consumes APIs (new or modified),
     produce an explicit API contract (endpoint paths, request/response schemas
     with field names and types, status codes, error shapes). For modified
     endpoints, show before/after. Save it in the logical design document.
     All code generated in Stage 4 (backend AND frontend) MUST conform to
     this contract. All test mocks MUST be derived from it.
{{#enterprise}}
     Guardrails validation:
     d) Verify all selected AWS services are approved and regionally available.
     e) Verify encryption, IAM, network, observability, and deployment 
        guardrails (same as Enterprise Mob Construction Stage 2).
     f) Reference specific EGS guardrails in each ADR.
{{/enterprise}}

   - Stage 4: Code Generation
     Generate executable code. For Brownfield:
     a) Clearly separate new code from modifications to existing code.
     b) Modifications to existing files must be minimal and surgical.
     c) Implement feature flags for new functionality.
     d) Generate adapter/anti-corruption layer code.
     e) Follow existing codebase conventions.
{{#enterprise}}
     Guardrails validation:
     f) No secrets in code (EGS Section 1.4).
     g) Structured JSON logging with mandatory fields (EGS Section 4.3).
     h) Error handling with correlation IDs (EGS Section 4.2).
     i) Explicit dependency versions (EGS Section 4.4).
{{/enterprise}}
     j) IaC includes mandatory tags (EGS Section 5.5).
     k) Health check endpoints (EGS Section 5.2).
     l) No PII in logs.
     m) If this Unit includes remediation stories, implement the fixes and 
        verify the before/after state matches the remediation criteria.

   - Stage 5: Test & Validation
     Generate and execute tests. The test suite MUST include:
     a) Functional tests: new functionality works as specified.
     b) Regression tests: existing functionality NOT broken.
     c) Integration tests: new code interacts correctly with existing 
        components.
     d) Backward compatibility tests: existing API consumers unaffected.
     e) Security tests: no new vulnerabilities.
     f) Performance tests: no degradation to existing system.
     g) Contract conformance: if an API contract was defined in Stage 3,
        validate that (i) backend responses match the contract schemas,
        (ii) frontend service calls expect the contract schemas, and
        (iii) every mock used in tests is derived from the contract, not
        invented. Flag any property name, type, or structure mismatch as
        a BLOCKER.
{{#enterprise}}
     g) ENTERPRISE ADDITION: Guardrail compliance tests:
        - Encryption validation (no unencrypted stores or channels).
        - IAM validation (no wildcards, least privilege).
        - Tagging validation (all mandatory tags present).
        - Secrets validation (no secrets in code/config).
        - Logging validation (structured, mandatory fields, no PII).
        - TLS validation (all endpoints encrypted).
     h) ENTERPRISE ADDITION: If this Unit includes remediation stories, 
        generate specific tests that validate the remediation (e.g., 
        "this S3 bucket that was previously unencrypted is now encrypted").
     i) Generate the Guardrails Compliance Report for this Bolt.
     Regression, backward compatibility, and Mandatory guardrail test 
     failures are BLOCKERS.
     Save report as: aidlc-docs/mob-construction/[current-bolt]/guardrails_report.md
{{/enterprise}}

2. All artifacts go in the aidlc-docs/ folder:
   - Domain models → aidlc-docs/mob-construction/[current-bolt]/domain_model.md
   - Integration design → aidlc-docs/mob-construction/[current-bolt]/integration_design.md
   - Logical design + ADRs → aidlc-docs/mob-construction/[current-bolt]/logical_design.md
   - Code → [project_folder]/
   - Adapter layers → [project_folder]/adapters/
   - Tests → [project_folder]/tests/
   - Regression tests → [project_folder]/tests/regression/
{{#enterprise}}
   - Guardrail compliance tests → [project_folder]/tests/guardrails/
{{/enterprise}}
{{#enterprise}}
   - Guardrails Compliance Report → aidlc-docs/mob-construction/[current-bolt]/guardrails_report.md
{{/enterprise}}
   - Decisions → append to aidlc-docs/decisions/decision-log.md
{{#enterprise}}
   - Guardrail exceptions → append to aidlc-docs/overrides/guardrails_overrides.md
{{/enterprise}}
   - Plans → aidlc-docs/
   - Prompt templates → aidlc-docs/prompts/

3. For each stage, 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 with pros/cons. 
{{#enterprise}}
   Reference applicable EGS guardrails. In Brownfield, the cost of a wrong 
{{/enterprise}}
   decision is higher.
   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, bolt ID, mode).
   - PRE_FLIGHT after pre-flight completes (log what was read, decisions loaded, dependencies checked).
   - PHASE_START / PHASE_COMPLETE at each stage boundary (log stage 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 bolt completes or user pauses.
   Use ISO timestamps. Keep entries concise (2-4 lines each).

7. **Overconfidence prevention:** Default to asking. In Brownfield, the cost
   of a wrong assumption is higher because it can break existing functionality.
   Red flags specific to Brownfield construction:
   - Assuming existing component behavior not documented in Code Elevation models.
   - Choosing to modify vs. wrap an existing interface without asking.
   - Selecting a migration strategy without presenting alternatives.
   - Inferring integration contracts from code alone without confirming with us.
   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 PRINCIPLES:
   - Minimal intrusion: modify the fewest existing components possible.
   - Adapter over modification: wrap existing interfaces.
   - Backward compatibility by default: existing consumers must not break.
   - Progressive enablement: use feature flags.
   - Regression is a blocker: failing regression tests stop the session.
{{#enterprise}}
   - ENTERPRISE ADDITION: Guardrail compliance is a blocker: failing 
     Mandatory guardrail tests stop the session.
{{/enterprise}}

{{#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
- Tech stack: [e.g., Python, TypeScript, Java]
- AWS services in use: [list existing services]
- AWS services preferences for new components: [e.g., Lambda, ECS, DynamoDB]
- IaC tool: [CloudFormation / CDK / Terraform]
- Target AWS account/region: [specify]
{{#enterprise}}
- Applicable regulatory frameworks: [from Mob Elaboration]
{{/enterprise}}
- Deployment strategy for this Bolt: [canary / feature flag / blue-green]
- Technical debt items to address in this Unit: [list from Elaboration triage]
{{#enterprise}}
- Guardrail remediation stories in this Unit: [list from Remediation Triage]
{{/enterprise}}
{{#enterprise}}
- Technical debt items explicitly deferred: [list]
{{/enterprise}}

## Start
Begin by reading ALL reference artifacts (Code Elevation models, Guardrails 
{{#enterprise}}
Gap Analysis, compatibility impact map, user stories, NFRs, risk register, 
Guardrails Compliance Matrix, Guardrails Remediation Triage). Then start 
{{/enterprise}}
Stage 1: Generate the Domain Model for this Unit, mapping new concepts to the 
existing system and annotating with data classification levels. Present the 
model for our validation before proceeding.
```

---

## Notes

{{#enterprise}}
- **All Enterprise prerequisites are mandatory.** Code Elevation (Enterprise) and Brownfield Mob Elaboration (Enterprise) must be completed with their full artifact sets including Guardrails Gap Analysis, Remediation Triage, and Compliance Matrix.
{{/enterprise}}
{{#enterprise}}
- **Guardrail remediation stories are first-class work items.** They are implemented in the appropriate stage (e.g., encryption fixes in Stage 4, architectural fixes in Stage 2/3) and validated with specific tests in Stage 5.
{{/enterprise}}
{{#enterprise}}
- **Two types of blockers in Enterprise Brownfield:** regression test failures AND Mandatory guardrail test failures. Both stop the session until resolved.
{{/enterprise}}
{{#enterprise}}
- **The Guardrails Compliance Report** tracks both new compliance (for new code) and remediation compliance (for fixes to existing code). This provides auditable evidence of improvement.
{{/enterprise}}
- **Sequencing:** If guardrail remediation is foundational (e.g., fixing IAM before building features that depend on proper auth), run the remediation Bolt first.
