fe711870be
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
86 lines
4.0 KiB
Markdown
86 lines
4.0 KiB
Markdown
---
|
|
name: aeries-product-visionary
|
|
description: 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)
|