RnD/EVOLV
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate to new Gitea instance (gitea.wbd-rd.nl)

Browse Source 
- Update all submodule URLs from gitea.centraal.wbd-rd.nl to gitea.wbd-rd.nl
- Add settler as proper submodule in .gitmodules
- Add agent skills, function anchors, decisions, and improvements
- Add Docker configuration and scripts
- Add manuals and third_party docs
- Update .gitignore with secrets and build artifacts
- Remove stale .tgz build artifact

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
znetsixe
2026-03-04 21:07:04 +01:00
parent fbd9e6ec11
commit 6a6c04d34b
169 changed files with 21332 additions and 1512 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
.agents/skills/evolv-orchestrator/SKILL.md
View File

@@ -8,26 +8,38 @@ description: Orchestrate multi-agent execution for the EVOLV repository. Use whe
## Mission
Coordinate specialized EVOLV agents, split work into clear tasks, and ensure integrations are coherent across JavaScript/CommonJS Node-RED nodes, process assets, and observability/data concerns.
## Harness-Style Operating Rules
- Start from the live repo state, not generic playbooks.
- Build a file-level impact map before assigning specialist work.
- Define invariants first, then implement changes.
- Require evidence for each claim (tests, smoke checks, endpoint validation, or concrete diffs).
- Convert repeated lessons into updated skill guidance to reduce future ambiguity.
## Execution Flow
1. Frame the objective and constraints in one paragraph.
2. Identify impacted areas in the repo before assigning work:
2. Build an impact map before assigning work. Identify touched contracts and files:
- `nodes/<nodeName>/<nodeName>.html` (editor UI)
- `nodes/<nodeName>/<nodeName>.js` (runtime entry)
- `nodes/<nodeName>/src/nodeClass.js` (Node-RED wrapper)
- `nodes/<nodeName>/src/specificClass.js` (domain logic)
- `nodes/generalFunctions/` (shared helpers/config)
3. Route tasks to specialist skills with explicit deliverables and acceptance criteria.
4. Require each specialist to return:
3. Declare invariants and acceptance criteria:
- backward compatibility posture: controlled breaks allowed only with migration
- safety posture: availability-first unless user overrides for a specific task
- security trust boundary/default behavior
- data schema/query compatibility where relevant
4. Route tasks to specialist skills with explicit deliverables and acceptance criteria.
5. Require each specialist to return:
- assumptions
- changed files
- tests added/updated
- unresolved risks
5. Integrate outputs and check cross-skill consistency:
6. Integrate outputs and check cross-skill consistency:
- config fields aligned between `.html` and runtime parsing
- admin endpoints stable (`/<nodeName>/menu.js`, `/<nodeName>/configData.js`)
- topic contracts (`msg.topic`) unchanged unless migration is defined
6. Ask targeted user interview questions only when decisions are ambiguous and unblock execution.
7. Produce a final integrated plan or implementation with a risk log.
7. Ask targeted user interview questions only at decision gates (see protocol below).
8. Produce a final integrated implementation with a risk log and decision log updates when needed.
## Delegation Map
- Use `evolv-frontend-node-red` for Node-RED editor/runtime UX and HTML config input design.
@@ -44,9 +56,28 @@ Ask at most 3 focused questions at a time. Prioritize:
2. Safety/availability constraints (what must never break).
3. Backward compatibility expectations for flows and topics.
Trigger an interview before finalizing when any of these are true:
- Breaking topic/payload/schema/API change is proposed
- Safety envelope or fail-safe defaults are loosened/tightened
- Security defaults or endpoint exposure changes
- Data retention/backfill/query behavior changes
- Rollout strategy has material operational risk
Default resolution rules when interviewing:
- prefer compatibility option with migration over undocumented hard breaks
- prefer availability-first behavior with explicit bounded safeguards
- always create/update a decision log entry for every decision-gate outcome
Question format:
- decision statement (one sentence)
- options with tradeoff
- recommended option and why
## Output Contract
Return:
- task breakdown by specialist
- execution order and dependencies
- measurable acceptance criteria
- integration risks and mitigation
- evidence summary (what was verified and how)
- decision log entries created/updated (if any)