Skip to content

Latest commit

 

History

History
30 lines (25 loc) · 3.68 KB

File metadata and controls

30 lines (25 loc) · 3.68 KB

Bilingual Navigation: English (this document) · Versión en Español

Project

Evolith Tracker - End-to-end tracking engine for the Evolith SDLC workflow. This is a satellite (child) repository that inherits its standards from the Evolith Upstream architectural baseline.

Agent Role

  • You are an AI assistant assigned to work on this satellite product.
  • Your primary goal is to help build and maintain the SDLC tracker while respecting the architectural baseline enforced by the upstream.
  • Whenever you propose a new technology or pattern, you must check if an applicable upstream ADR exists, and explicitly register any divergence in the DECISIONS.md file.
  • Core Communication: All communication with Evolith Core MUST go through the Core BFF Gateway (ADR-0008/0030/0075). Direct internal service calls to Core are forbidden for satellite repositories. The Tracker authenticates with the B2B API Gateway pattern (API key) and routes through Tier 1 Kong Edge → Tier 2 NestJS BFF → Core internal services.
  • BMAD Expert Mode: For implementation, design, review, DevOps, security, SRE, UX/UI, data or architecture work, load the BMAD Master Agent Team operating standard before acting. Use it as the professional quality bar while still applying the local and upstream constraints in this file.

Local Rules and Conventions

  • Decision Inheritance: Do not assume full architectural autonomy. Evolith's base decisions (e.g., database engine, gateway, naming conventions) apply by default unless explicitly overridden in DECISIONS.md.
  • Navigation: Use MASTER_INDEX.md to orient yourself around the repository structure and README.md for general product context.
  • Business Domain: Familiarize yourself with reference/knowledge/domain/glossary.md and use the terminology consistently in code and documentation.
  • SDLC Workflow: Since this is the SDLC tracking engine, all features you build must align with Evolith's SDLC governance and phases.
  • Gap Register Governance: Gap, opportunity, and coherence tracking must be maintained only in docs/audit/tracker-gaps-opportunities-tracking.md. Keep a single master table, order pending items first, categorize every row, and link each ID to its detail section in the same file. Do not create separate docs/audit/gaps/*.md, docs/audit/opportunities/*.md, or split pending/resolved tables.
  • BMAD Naming: Use the BMAD-proposed names already installed in the local BMAD toolchain: Mary (Business Analyst), John (Product Manager), Sally (UX Designer), Winston (System Architect), Amelia (Senior Software Engineer), and Paige (Technical Writer). Use John, not Jhon, unless quoting a historical artifact.

Architecture-Related Tasks

  • If a task requires a significant architectural decision, you must follow the ADR process:
    1. Check for an upstream pattern.
    2. Draft the local ADR (Adopt, Extend, Override, N/A).
    3. Register it in the DECISIONS.md table.

Tactical DDD & Implementation Rules

  • Cross-Cutting Shells: Do not implement infrastructure plumbing (configuration, state machines, bulk parsing) inside Bounded Contexts. You must inject and use @evolith/workflow-engine, @evolith/tenant-config, and @evolith/integration-fabric.
  • Small Aggregates Pattern: When designing massive 1:N relationships (e.g., Backlog -> UserStories), never nest complete objects. Use UUID references (List<UUID> storyIds) to prevent concurrency deadlocks.
  • Dynamic Workflows: State transitions must be protected by evaluating the Aggregate's internal RequirementChecklist, which is injected by the WorkflowEngine upon creation.