glm-5.1
835724d087
The remaining task descriptions implied that downstream concerns (StorageIdentityProvider, irpc service layer, agent services, multi-node deployment) already exist. Updated to clearly distinguish: - spec-update-server: Phase 1 ships ConfigIdentityProvider, not irpc auth - spec-update-call-protocol: Phase 1 is local dispatch only; irpc and remote dispatch are contracted for later. Agent services are downstream concerns. - spec-update-overview: Note which crates exist now vs which are Phase 2+ contracts - review-spec-foundation: Add phase boundary check to acceptance criteria
2.9 KiB
2.9 KiB
id, name, status, depends_on, scope, risk, impact, level
| id | name | status | depends_on | scope | risk | impact | level | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| architecture/review-spec-foundation | Review Phase 0 specs — validate consistency, completeness, and ADR alignment | pending |
|
broad | low | project | review |
Description
Review all Phase 0 spec documents after they're written. This is the Phase 0 review checklist from the integration plan, applied against the actual deliverables.
Acceptance Criteria
- No inline decision rationale — all "why" decisions are in ADRs, specs reference ADR numbers
- No inline open questions — all OQs are in open-questions.md, specs reference OQ numbers
- Terminology is consistent — head/worker everywhere (no hub/spoke in specs, ADRs retain historical language)
- Layer boundaries are clear — every component belongs to exactly one layer (Transport, Interface, Protocol)
- Phase boundaries are clear — specs distinguish what ships in Phase 1 (ConfigIdentityProvider, ArcSwap, local dispatch) from what's contracted for later (StorageIdentityProvider, irpc service layer, application services, multi-node deployment). No spec should imply that alknet-storage, alknet-secret, or the irpc service implementations already exist.
- Every spec has YAML frontmatter with status and last_updated
- Identity is consistently defined — Identity struct is
{id, scopes, resources}everywhere (identity.md is canonical, auth.md references it) - OperationEnv is consistently described — three dispatch paths match across services.md, call-protocol.md, and identity.md
- irpc positioning is consistent — always described as one dispatch backend for OperationEnv, never as a replacement for the call protocol
- Interface trait is consistent — SshInterface and RawFramingInterface match across interface.md and server.md
- ForwardingPolicy is consistently placed — in DynamicConfig, checked before proxy spawn, reference in server.md and configuration.md
- README.md and ADR table include all new documents and ADRs
- No broken links between doc references
- All specs follow the format: What, Why, Architecture, Constraints, Open Questions, Design Decisions
References
- docs/research/integration-plan.md — Phase 0: Review Checklist
- docs/architecture/ — all architecture docs
Notes
To be filled by implementation agent
Summary
To be filled on completion