RnD/EVOLV

Files

znetsixe d4e72f280e docs: retire repo-mem MCP, migrate skills to .claude/skills, audit fixes

- Delete .mcp.json + .claude/rules/repo-mem.md; drop .repo-mem from .gitignore
- Remove repo-mem / substrate_score / repo_search references from all .md
- Move 15 EVOLV skills from .agents/skills/ to .claude/skills/ so they are
  auto-discovered by the Claude Code harness and invokable via the Skill tool
- Retire .agents/skills/evolv-orchestrator (duplicate of the subagent at
  .claude/agents/evolv-orchestrator.md); orchestrator lives as a subagent only
- Drop OpenAI-format agent yaml metadata from each skill (not needed for CC)
- Update CLAUDE.md, CONTRACTS.md, AGENTS.md to point at the new locations and
  disambiguate skills (.claude/skills/) vs subagents (.claude/agents/)
- Fix CLAUDE.md tick-loop wording (opt-in per-node, not a fixed 1000ms)
- Widen .claude/rules/ paths frontmatter so node-architecture and telemetry
  rules trigger on more relevant files; add frontmatter to flow-layout rule
- Bump CONTRACTS.md review date to 2026-05-19; add step 7 to the contract-
  change workflow (review example flows when topic usage changes)
- Bump nodes/generalFunctions pin (Home.md substrate_score reference removed)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-19 09:30:49 +02:00

2.2 KiB

Raw Permalink Blame History

name, description

name	description
evolv-database-influx-architecture	Design and review EVOLV data modeling and storage architecture for telemetry and dashboard consumption. Use when deciding InfluxDB measurement/tag/field schemas, retention/downsampling strategy, write/read payload structures, and Grafana query compatibility for Node-RED outputs.

EVOLV Database Influx Architecture

Mission

Shape telemetry data so it is queryable, performant, and maintainable for operations dashboards and analytics.

Harness Execution Contract

Start from current measurement/tag/field usage and dashboard queries.
Define invariants before edits:
- query compatibility for existing Grafana/consumer flows
- bounded tag cardinality
- explicit units and timestamp policy
Provide validation evidence using representative payloads and queries.

Scope

Output payload structure from EVOLV nodes
InfluxDB write model: measurement, tags, fields, timestamp policy
Retention/downsampling implications for Grafana visualization

Workflow

Classify data by usage:

real-time control
operator dashboarding
long-term analytics

Define stable schema conventions:

measurement naming
tag cardinality controls
numeric fields and units

Validate that node outputs map cleanly to write model.
Check query ergonomics for expected Grafana panels.
Specify retention/downsampling and backfill behavior.

Design Rules

Avoid high-cardinality tags for volatile identifiers.
Keep units explicit and consistent over time.
Prefer additive schema evolution; document breaking changes.
Include timestamps that are consistent across nodes.

Test/Validation Expectations

Verify sample payloads produce intended point shape.
Check representative queries for latency and result correctness.
Include migration strategy when schema changes are unavoidable.

Deliverables

Return:

proposed schema (measurement/tags/fields)
rationale tied to dashboard and analytics use
changed files/tests
migration and retention plan

Decision interview triggers:

schema changes that break existing queries/panels
retention/downsampling policies with data-loss tradeoffs
backfill rules that alter historical comparability

2.2 KiB Raw Permalink Blame History