research-protocol

Research and Monitoring Protocol

Monitor the project's dependency health, track the competitive landscape, and surface new techniques that could benefit the project. File GitHub issues for every actionable finding.

Focus: $ARGUMENTS (default: full — all phases)

Mandatory Reading

Read all reference files before starting:

• Research Protocol — research methodology, competitive parity, dependency monitoring
• Issue Management — anomaly classification, P0-P4 labels, filing template
• SDD Integration — when and how to spawn the sdd agent before filing

Hard Rules

1. NEVER modify source code — not even Cargo.toml dependency versions
2. ALL findings become GitHub issues — implementation happens in separate sessions
3. You MAY write ONLY to .local/testing/ and .local/specs/

Phase 1: Dependency Monitoring (dependencies, full)

cargo outdated --workspace          # Version drift
cargo deny check advisories         # Security advisories (RUSTSEC)

Update priority and issue filing — see Research Protocol.

For major version bumps or security advisories: spawn sdd agent before filing (see SDD Integration). Routine patch/minor updates: file directly.

Phase 2: Research & Innovation (research, full)

Search for new techniques relevant to the project's domain:

• Architectural patterns, concurrency models, state machines
• Performance techniques: zero-copy, SIMD, memory layout
• Safety practices: compile-time guarantees, typestate, capability-based design
• Ecosystem evolution: new crates, deprecated dependencies, emerging standards
• Tooling improvements: profiling, debugging, testing frameworks

For each finding:

1. Assess: impact on project quality vs implementation complexity
2. Spawn sdd agent to produce a spec (all research findings require a spec)
3. Check for duplicate issues before filing
4. File research issue with source links, implementation sketch, spec path

Phase 3: Competitive Parity (parity, full)

Identify reference projects in the same domain, review their recent changelogs, and assess capability gaps. See Research Protocol for the full scan procedure.

Parity gap severity:

• P1 — active incompatibility with a first-class integration target
• P2 — meaningful capability that 2+ reference projects have and users would notice
• P3 — useful feature, low urgency
• P4 — cosmetic or niche difference

Update .local/testing/playbooks/competitive-parity.md after each scan.

Session Exit

Before finishing:

1. Append session retrospective to .local/testing/process-notes.md
2. Print a summary: dependency advisories found, research issues filed, parity gaps identified
3. Write handoff with Research Results section listing all filed issue URLs and spec paths