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>
54 lines
2.2 KiB
Markdown
54 lines
2.2 KiB
Markdown
---
|
|
name: evolv-regulatory-compliance-wastewater
|
|
description: Apply wastewater regulatory and compliance constraints to EVOLV control and telemetry design. Use when reviewing effluent-quality KPIs, reporting semantics, auditability, traceability of control actions, and compliance-impacting alarm/control decisions.
|
|
---
|
|
|
|
# EVOLV Regulatory Compliance Wastewater
|
|
|
|
## Mission
|
|
Ensure EVOLV changes remain auditable and aligned with wastewater compliance/reporting obligations.
|
|
|
|
## Harness Execution Contract
|
|
- Map compliance-relevant outputs and control decisions from current repo contracts.
|
|
- Define invariants before edits:
|
|
- compliance KPIs remain traceable
|
|
- auditability of major control actions is preserved
|
|
- reporting semantics are stable or explicitly migrated
|
|
- Validate with evidence that supports audit/review workflows.
|
|
|
|
## Scope
|
|
- Effluent-related outputs and quality calculations in process nodes
|
|
- Alarm and control behaviors that affect permit-critical operation
|
|
- Telemetry/reporting contracts consumed by dashboards/reports
|
|
|
|
## Workflow
|
|
1. Identify compliance-relevant metrics and events.
|
|
2. Trace data lineage from sensor/input to reported output.
|
|
3. Verify timestamp/quality metadata sufficiency for audits.
|
|
4. Review alarm/control actions that can affect permit outcomes.
|
|
5. Define documentation and test evidence for compliance-critical paths.
|
|
|
|
## Standards
|
|
- Prefer explicit semantics over inferred compliance logic.
|
|
- Preserve historical comparability of compliance KPIs.
|
|
- Ensure traceability of overrides, trips, and degraded operation.
|
|
- Keep evidence artifacts reproducible and review-friendly.
|
|
|
|
## Test Expectations
|
|
Cover:
|
|
- compliance KPI payload consistency
|
|
- traceability fields presence (timestamp/source/quality where applicable)
|
|
- alarm/control transitions relevant to permit risk
|
|
- behavior under missing or suspect compliance measurements
|
|
|
|
## Deliverables
|
|
Return:
|
|
- compliance impact map and assumptions
|
|
- changed files/tests with audit-focused evidence
|
|
- unresolved compliance risks and mitigation recommendations
|
|
|
|
Decision interview triggers:
|
|
- any change that can alter reported compliance values
|
|
- changed retention/backfill semantics for compliance reporting
|
|
- reduced auditability or traceability in control/telemetry paths
|