Mathias STRASSER
e745cf326a
Les enseignants ont besoin de moyennes à jour immédiatement après la publication ou modification des notes, sans attendre un batch nocturne. Le système recalcule via Domain Events synchrones : statistiques d'évaluation (min/max/moyenne/médiane), moyennes matières pondérées (normalisation /20), et moyenne générale par élève. Les résultats sont stockés dans des tables dénormalisées avec cache Redis (TTL 5 min). Trois endpoints API exposent les données avec contrôle d'accès par rôle. Une commande console permet le backfill des données historiques au déploiement.
96 lines
3.0 KiB
Markdown
96 lines
3.0 KiB
Markdown
---
|
|
title: 'Module Plan'
|
|
status: 'ideation'
|
|
module_name: ''
|
|
module_code: ''
|
|
architecture: ''
|
|
standalone: true
|
|
expands_module: ''
|
|
skills_planned: []
|
|
config_variables: []
|
|
created: ''
|
|
updated: ''
|
|
---
|
|
|
|
# Module Plan
|
|
|
|
## Vision
|
|
|
|
<!-- What this module does, who it's for, and why it matters -->
|
|
|
|
## Architecture Decision
|
|
|
|
<!-- Agent-centric / workflow-centric / hybrid — and the reasoning behind the choice -->
|
|
|
|
## User Experience
|
|
|
|
<!-- Who uses this module and what their journey looks like -->
|
|
|
|
## Skills
|
|
|
|
<!-- For each planned skill, copy this block: -->
|
|
|
|
### {skill-name}
|
|
|
|
**Type:** {agent | workflow}
|
|
**Purpose:**
|
|
|
|
**Capabilities:**
|
|
|
|
| Display Name | Menu Code | Description | Action | Args | Phase | After | Before | Required | Output Location | Outputs |
|
|
| ------------ | --------- | ----------- | ------ | ---- | ----- | ----- | ------ | -------- | --------------- | ------- |
|
|
| | | | | | | | | | | |
|
|
|
|
**Design Notes:**
|
|
|
|
## Memory Architecture
|
|
|
|
<!-- For multi-agent modules: personal sidecars only, personal + shared module sidecar, or shared only? -->
|
|
<!-- What shared context should agents contribute to? (user style, content history, project assets, etc.) -->
|
|
<!-- If shared only — consider whether a single agent is the better design -->
|
|
|
|
## Configuration
|
|
|
|
| Variable | Prompt | Default | Result Template | User Setting |
|
|
| -------- | ------ | ------- | --------------- | ------------ |
|
|
| | | | | |
|
|
|
|
<!-- Reminder: skills should have sensible fallbacks if config hasn't been set, or ask at runtime for values they need -->
|
|
|
|
## External Dependencies
|
|
|
|
<!-- CLI tools, MCP servers, or other external software that skills depend on -->
|
|
<!-- For each: what it is, which skills need it, and how the setup skill should handle it -->
|
|
|
|
## UI and Visualization
|
|
|
|
<!-- Does the module include dashboards, progress views, interactive interfaces, or a web app? -->
|
|
<!-- If yes: what it shows, which skills feed into it, how it's served/installed -->
|
|
|
|
## Setup Extensions
|
|
|
|
<!-- Beyond config collection: web app installation, directory scaffolding, external service configuration, starter files, etc. -->
|
|
<!-- These will need to be manually added to the setup skill after scaffolding -->
|
|
|
|
## Integration
|
|
|
|
<!-- Standalone: how it provides independent value -->
|
|
<!-- Expansion: parent module, cross-module capability relationships, skills that may reference parent module ordering -->
|
|
|
|
## Creative Use Cases
|
|
|
|
<!-- Beyond the primary workflow — unexpected combinations, power-user scenarios, creative applications discovered during brainstorming -->
|
|
|
|
## Ideas Captured
|
|
|
|
<!-- Raw ideas from brainstorming — preserved for context even if not all made it into the plan -->
|
|
|
|
## Build Roadmap
|
|
|
|
<!-- Recommended build order for skills -->
|
|
|
|
**Next steps:**
|
|
|
|
1. Build each skill using **Build an Agent (BA)** or **Build a Workflow (BW)** — share this plan document as context
|
|
2. When all skills are built, return to **Create Module (CM)** to scaffold the module infrastructure
|