d4e72f280e
- 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>
59 lines
2.2 KiB
Markdown
59 lines
2.2 KiB
Markdown
---
|
|
name: evolv-database-influx-architecture
|
|
description: 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
|
|
1. Classify data by usage:
|
|
- real-time control
|
|
- operator dashboarding
|
|
- long-term analytics
|
|
2. Define stable schema conventions:
|
|
- measurement naming
|
|
- tag cardinality controls
|
|
- numeric fields and units
|
|
3. Validate that node outputs map cleanly to write model.
|
|
4. Check query ergonomics for expected Grafana panels.
|
|
5. 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
|