jpmschweitzerandClaude Opus 4.6
e6a557e8e7
Sprint-based workflow (38 sprints) replaced by kanban + milestones. Milestones are many-to-many with tickets and can block each other. New: /whats-next skill (dependency-driven batch selection with Si refinement review), /pr-process skill (renamed from pr-push, adds review comment pickup), clerk agent + pre-push hook for D-record consistency checks. Deleted: sprint CLI, sprint-start/sprint-plan/sprint-status skills, team-scoped file restrictions. Si rewritten as refinement manager. All 19 agent briefings updated from stale PROJECT_STATE.md reference to live ticket milestone queries. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
74 lines
4.1 KiB
Markdown
74 lines
4.1 KiB
Markdown
---
|
|
title: "Hoshe - Project Briefing"
|
|
description: "QA and test infrastructure agent — owns generator output validation, integration tests, content schema validation, and legibility test criteria for the v0.2 generator spike"
|
|
type: briefing
|
|
status: active
|
|
agent: Hoshe
|
|
updated: 2026-03-13
|
|
---
|
|
|
|
# Hoshe - Project Briefing
|
|
Last updated: 2026-03-13
|
|
|
|
## Current Project State
|
|
Check active milestones: `tooling/db/ticket milestone list`
|
|
Check your tickets: `tooling/db/ticket list --assigned hoshe`
|
|
|
|
## Status
|
|
**ACTIVE.** Test infrastructure from earlier sprints is operational. v0.2 focus: generator output validation — can the generator produce legible NPCs? Are relationships readable from generator output?
|
|
|
|
## Decisions Relevant to Your Role
|
|
Read `decisions/architecture.md` (D-010, D-020, D-030) and `decisions/perception.md` (D-011, D-017, D-018). Key decisions:
|
|
- **D-010:** Information boundaries — testable? Can we verify information never leaks?
|
|
- **D-020:** MessagePack serialization — correct round-trip? No data loss at protocol boundary?
|
|
- **D-030:** Testability architecture (hybrid Rust tests, gdUnit4, three-layer IPC, CauseChain)
|
|
- **D-119:** Generator spike — Phase 5 per D-166 cascade (not imminent). Success criterion: "can the player read NPC relationships from generator output?" Hoshe defines and verifies this criterion.
|
|
|
|
## What's Been Delivered (Sprints 2-4)
|
|
### Test infrastructure now in place:
|
|
- Integration test: tile type data in live server mode (#410, Sprint 4)
|
|
- Integration test: input roundtrip through live server (#411, Sprint 4)
|
|
- Knowledge graph unit test suite (#367, Sprint 2)
|
|
- `make validate-content` CLI (#392, Sprint 3)
|
|
|
|
### Content pipeline (testable surface):
|
|
- YAML content loader Phase 2 (#408) — content loading is live
|
|
- Content schema definitions (#386) — validation rules exist
|
|
- Global knowledge files (#388) — canonical FactId source for validation
|
|
- Line previewer CLI (#407) — can verify content loads without errors
|
|
|
|
## Current Priorities
|
|
Consult `docs/sprints/` for active sprint briefing.
|
|
|
|
### Generator spike validation (v0.2 critical path):
|
|
1. **Generator output legibility test plan** — define what "can the player read NPC relationships from generator output?" means as a testable criterion. Produce test plan before the Sprint 25 generator spike begins.
|
|
2. **NpcBlueprint struct tests** — when Tyre delivers the NpcBlueprint struct design, write unit tests verifying the 10-axis model (D-024) is correctly encoded in generator output.
|
|
3. **Generated NPC relationship readability test** — functional test: given a generated location with generated NPCs, can a blind observer describe social relationships correctly? Design the test protocol.
|
|
|
|
### Infrastructure maintenance:
|
|
4. **Verify existing integration tests still pass** — regression check after any architectural changes
|
|
5. **Test harness improvements** — reusable fixtures for server+client pairs
|
|
6. **Dedicated test map** — minimal map for routing, pathfinding, visibility, protocol correctness (not dependent on hand-authored content)
|
|
7. **Edge case coverage** — malformed packets, disconnects, entities at map edges, interactions at max range
|
|
|
|
## Development Workflow
|
|
See `docs/DEVOPS.md` for full procedures. Your key targets:
|
|
- `make test` — run all tests (server + client)
|
|
- `make test-server` — Rust unit + integration tests
|
|
- `make test-client` — gdUnit4 tests (headless runner pending)
|
|
- `make lint` — run all linters
|
|
- `make ci` — full CI pipeline locally (lint -> build -> test)
|
|
- `make validate-content` — content schema validation
|
|
- Server tests: `server/` (inline `#[cfg(test)]` + `tests/` directory per D-030)
|
|
- Client tests: `client/` (gdUnit4 per D-030)
|
|
- Cross-boundary tests: `tests/` (IPC fixtures, serialization round-trips)
|
|
- Test caches: `.cache/` (gitignored, cleared by `make clean`)
|
|
|
|
## Key Documents
|
|
- decisions/ — domain-split decision files (see decisions/README.md for index)
|
|
- docs/DEVOPS.md — build, test, lint, CI procedures
|
|
- docs/sprints/ — current sprint briefings
|
|
- docs/workshops/wheres-the-fun/workshop-outcomes.md — v0.2 success criteria context
|
|
- tests/ — integration and end-to-end tests
|
|
- TEAM.md — team roster
|