jordan/tidaldb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
69ae6e64a1
tidaldb/.agents/skills/aeries-product-visionary/SKILL.md
jordan.washburn fe711870be feat: M8 phases 7-10 — gRPC transport, cluster server, scatter-gather, multi-node UAT 
Delivers the distributed fabric's network layer and HTTP cluster surface:

**m8p7: tidal-net crate (gRPC transport)**
- GrpcTransport implementing Transport trait via tonic 0.12
- Per-peer circuit breaker (Closed/Open/HalfOpen), mutual TLS via rustls
- Boxed error types (clippy-clean), graceful mutex recovery, debug_assert
  against calling block_on from tokio context
- Proto: WalShipping service (ShipSegment, StreamSegments stub, Heartbeat)
- 19 tests: contract, mTLS, reconnection, multi-node UAT, benchmarks

**m8p8: cluster subcommand + HTTP routes**
- ClusterState wrapping SimulatedCluster with region name mapping
- Routes: /health, /cluster/status, /cluster/promote, /partition, /heal
- Data routes: /items, /embeddings, /signals, /feed, /search (region-aware)
- Ranking profiles wired through ClusterConfig to all cluster nodes
- Topology YAML config, docker/cluster/Dockerfile (ENTRYPOINT+CMD, non-root)

**m8p9: scatter-gather query routing**
- Entity-sharded writes via Knuth multiplicative hash
- Scatter-gather RETRIEVE and SEARCH with deadline propagation (50ms-5ms)
- Partial failure: degraded=true with unavailable_shards metadata
- 6 tests: distribution, determinism, multi-shard retrieve, degraded
  partial results, deadline propagation, scatter-gather search

**m8p10: gRPC transport integration tests**
- 8 tests over real gRPC: replication convergence, idempotent replay,
  mixed signals, 3-node fan-out, partition/heal, degraded follower, perf
- Documented as tier-2 (in-process+gRPC); tier-3 multi-process pending
2026-04-11 13:51:08 -06:00

4.0 KiB
Raw Blame History

name description
aeries-product-visionary Define Aeries product strategy, adaptation loops, milestones, and companion personality

aeries-product-visionary

When to Use

  • Defining what Aeries should do next (scoping milestones, prioritizing features)
  • Designing how iknowyou's learning loop manifests as user experience
  • Making decisions about companion personality, voice, and behavior
  • Writing UAT scenarios for milestone acceptance
  • Resolving product ambiguity (what to build vs. defer, what feels right vs. what's technically possible)

Invoked via: /aeries-product-visionary or delegated from /aeries-fullstack-engineer

Delegation

This skill delegates to @mira-vasquez — the Aeries product visionary. All product decisions, milestone scoping, adaptation design, and personality definition go through her lens.

Step Back

Before making any product decision, ask:

  1. What will the user notice? If the answer is "nothing visible," it's infrastructure — defer it until a user-facing feature needs it.
  2. Does this pass the friend test? Would this behavior feel attentive or invasive if a human friend did it?
  3. Can we UAT this? If you can't write a scenario where a real person tests it and says "yes, this works," it's not ready to scope.
  4. What's the smallest version? The MVP of every feature is "does the conversation feel better?" Not dashboards, not settings, not analytics.
  5. Are we optimizing for the right thing? "User came back voluntarily" > "time spent in conversation" > "messages sent." The first is a companion metric. The others are engagement traps.

Workflow

Phase 1: Context

  • Read applications/iknowyou/vision.md for the product thesis
  • Read applications/iknowyou/architecture.md for technical capabilities
  • Check existing milestones in applications/iknowyou/milestones/
  • Review signal schema and what learning primitives are available

Phase 2: Define

  • Write the UAT scenario first: what does the user do, what do they see?
  • Define the "aha moment" — the single thing that makes the user feel known
  • Scope the minimum signals needed (< 5 for any single milestone)
  • Identify what to explicitly defer and why

Phase 3: Validate

  • Walk through 10 turns of conversation with the feature active
  • Annotate what the system learns at each turn
  • Verify the adaptation would feel attentive, not creepy
  • Check that user control exists (inspect, correct, reset)

Phase 4: Document

  • Write milestone doc following tidalDB roadmap format
  • Include: thesis, UAT scenario, phases, deferred items, done-when gate
  • Complexity labels only (S/M/L/XL) — no calendar estimates

Quick Reference

Path Purpose
applications/iknowyou/vision.md Product vision and thesis
applications/iknowyou/architecture.md Technical architecture and signal schema
applications/iknowyou/aeries.md Companion personality definition
applications/iknowyou/adaptation.md iknowyou learning loop design
applications/iknowyou/milestones/ Milestone documents
applications/iknowyou/uat/ UAT scenarios
.Codex/agents/mira-vasquez.md Visionary agent — principles and constraints

Standards

  • Every milestone has a UAT scenario written before phase decomposition
  • Every feature has a defined "aha moment" — what the user notices
  • Signal design justified in human terms ("they care about this") not technical terms ("14-day half-life")
  • User control (inspect, correct, reset) designed alongside every learning feature
  • Personality and voice documented explicitly, not left to the model's defaults

Done Gate

  • UAT scenario written and walkable (a real person could test this)
  • "Aha moment" defined in one sentence
  • Signal requirements scoped (≤ 5 new signal types per milestone)
  • User control mechanism defined (how to inspect, correct, or disable)
  • Friend test passed (attentive, not invasive)
  • Deferred items listed with explicit rationale
  • Milestone follows tidalDB roadmap format (thesis, UAT, phases, done-when)