This repository is the governance and enablement workspace for the modernization of EOS Beestone, the client's energy-contract-lifecycle management application. It is not the application's source code — it hosts the methodology, training materials, and decisions that steer how the modernization gets done.
EOS Beestone has been developed since 2014 and is currently a Java 17 / Spring 6 / Hibernate 6 monolith (Tomcat, PostgreSQL, single WAR, classical MVC), live in Belgium and already deployed as a separate instance in Italy, with hard-coded workflows and business rules driven by ~120 Excel files imported into the DB — one column of each rule table holds Groovy code executed as dynamic logic. This Excel+Groovy combination is a single mechanism, not two (confirmed by Antoine 2026-07-29; see eos-audit-findings.md). A back-office GUI to replace Excel as the authoring step is planned but is not required for the Poland release. The application runs well (80% unit test coverage) but has no end-to-end tests and no existing documentation. Source code access is not yet in place at the time of writing.
Italy was deployed largely "as is," customized locally with its own Excel config files. The customer does not want that pattern repeated for Poland: Poland requires real architecture refactoring, a basic product catalog (no back office), and the pricing-engine replacement ("compute") as part of the release itself.
A contractor audit (eos-audit-findings.md) gives the first measured picture of the codebase's actual scale: ~380k LOC across 17 modules, two of which (Core & Common Core, ~100k LOC) are heavily depended-upon by the rest — "a monolith really." 530+ tables, ~75 batch jobs coordinating with interactive screens through the DB, and only a partial API on top of Spring MVC.
The target is a multi-tenant platform on Azure, microservices with Spring Boot, serving roughly a dozen additional markets alongside Belgium and Italy, with a new product catalog and a third-party "compute" service replacing the internal pricing engine. Whether a workflow engine and/or a standard rules engine are worth adopting is still an open question — Apache KIE (Kogito for workflow, Drools for business rules) is the leading candidate to study once repo access exists, as a standard replacement for the hard-coded workflow and Groovy-embedded rules. The critical-path constraint driving sequencing: the Poland market must launch in June 2027, with a reduced scope (basic product catalog without back office, the compute integration, microservice-ready technology only).
- Training & AI-agent enablement — get the development team fluent with GitHub Copilot before real modernization work starts on the codebase.
- Technical debt reduction / retro-documentation — recover the architecture, data model, API surface, and business-rule knowledge the legacy application never wrote down.
- Refactoring — the code changes needed en route to a microservices / multi-tenant target, sequenced against the Poland deadline.
- New & changed features — the product catalog, the "compute" pricing integration, and the workflow/rules-engine arbitration.
retro-documentation-harness-plan.md— methodology and roadmap for the AI-augmented retro-documentation harness (pillar 2).eos-audit-findings.md— findings from an external contractor's 2-slide audit of the actual codebase: scale, multi-country deployment status, and reuse opportunities. First measured (non-self-reported) data point on the application.roadmap.md— phase-level roadmap for pillars 1–4: training/retro-documentation, the e2e testing harness, and the architecture evolution toward the Poland gate, with the decisions and open items behind each phase.test-strategy.md— the e2e testing harness in detail: Cucumber + MockMvc (not Selenium), why, feasibility with a worked example, and what it does and doesn't cover.progress-update.pptx— client-facing wrap-up deck (SCIAM template, 16 slides): the audit, what's been delivered so far (including this governance repo's own structure and content, plus a dedicated look at the test strategy), why e2e testing is treated as one of the highest-stakes parts of the modernization — no safety net means no real confidence in refactoring, and the tests themselves must evolve alongside the Spring MVC → Spring Boot migration — the Gherkin scenario stays fixed, only the driver underneath evolves, the three-phase roadmap, and a focus on the training program as the immediate next step.training/— materials for the first Copilot enablement session (pillar 1):AGENTS.md— baseline context template to commit at the Beestone repo root.skills/—SKILL.mdtemplates for the four harness domains (architecture, data model, API surface, business rules).copilot-prompts-library.md— starter prompts for each domain, calibrated for a first hands-on session.environment-setup-checklist.md— attendee setup, currently written for IntelliJ IDEA (2026.2+) with native Copilot integration on Windows, using git checkpoints for keyboard rotation.theory-slides/— the Part 1 (theory) slide deck, built as Slidev (slides-as-code). Work in progress, not a final deck — Antoine needs more time to prepare this content for an actual training session. Every slide carries a "Draft — work in progress" badge so this stays visible wherever the deck is viewed, not just in this README.
prompts-log.md— verbatim log of the prompts used to produce this repository's content, kept as a worked example of how this kind of work gets driven with an AI agent.
- Repo access to the actual Beestone codebase — expected within days of 2026-07-29, ahead of the training.
- Retro-documentation harness methodology drafted (2026-07-29).
- Training Part 2 materials drafted — environment config and starter prompts (2026-07-29).
- [~] Training Part 1 theory slides — work in progress (
training/theory-slides/), more content expected. - [~] Training roadmap / session content (pillars 1 & 2 timeline) — phase-level shape defined in
roadmap.md; detailed session-by-session agenda still to do. - Refactoring & new-feature roadmap toward the Poland June 2027 gate (pillars 3 & 4) — see
roadmap.md: Cucumber-based e2e harness scoped to Poland-critical paths, then Spring Boot 4 + Spring Modulith. Two items inside it stay open until repo access exists (batch-flow testing approach, UI test driver).
All documentation in this repository is in English — third parties on this program are not French-speaking.