tasks: add 5 cleanup tasks from Phase 1 review, mark review complete

Review found Phase 1 approved with minor issues. Created cleanup tasks:
- napi-identity-provider-wiring (bug: NAPI bypasses IdentityProvider)
- panic-free-static-config (code smell: panic/unwrap in production path)
- non-exhaustive-public-api (future-proofing public API types)
- adr-doc-comments (doc convention: ADR references in new modules)
- ssh-session-recv-stub-doc (documentation: mark stubs as planned)
This commit is contained in:
2026-06-08 04:35:52 +00:00
parent 9d50082a49
commit eed3396705
6 changed files with 228 additions and 3 deletions

View File

@@ -0,0 +1,42 @@
---
id: cleanup/adr-doc-comments
name: Add ADR number references to doc comments in new modules
status: pending
depends_on:
- review/phase1-core-modifications
scope: narrow
risk: trivial
impact: isolated
level: implementation
---
## Description
The existing codebase has a pattern of referencing ADR numbers in doc comments (e.g., `transport/mod.rs` references ADR-001). The new Phase 1 modules should follow the same pattern for discoverability.
**Modules needing ADR references**:
- `auth/identity.rs` → ADR-029, ADR-028
- `config/forwarding.rs` → ADR-031
- `config/static_config.rs` → ADR-030
- `config/dynamic_config.rs` → ADR-030
- `config/config_service.rs` → ADR-030
- `call/mod.rs` → ADR-024, ADR-033
- `call/spec.rs` → ADR-025, ADR-033
- `interface/mod.rs` → ADR-026
## Acceptance Criteria
- [ ] Module-level doc comments reference relevant ADR numbers
- [ ] Style matches existing ADR references in the codebase (e.g., `//! See ADR-029.`)
## References
- crates/alknet-core/src/transport/mod.rs — existing pattern to follow
## Notes
> Suggested during Phase 1 review (S2)
## Summary
> To be filled on completion

View File

@@ -0,0 +1,50 @@
---
id: cleanup/napi-identity-provider-wiring
name: Fix NapiServerHandler to use IdentityProvider and ForwardingPolicy
status: pending
depends_on:
- review/phase1-core-modifications
scope: moderate
risk: medium
impact: component
level: implementation
---
## Description
The `NapiServerHandler` in `crates/alknet-napi/src/serve.rs` bypasses the `IdentityProvider` trait contract, calling `config.auth.authenticate_publickey()` directly instead of `IdentityProvider::resolve_from_fingerprint()`. This creates two problems:
1. **No Identity stored on session**: Without resolving through `IdentityProvider`, no `Identity` struct is attached to the connection. Per-identity forwarding rules (`principals` field in `ForwardingRule`) cannot match because there's no identity to match against.
2. **No forwarding policy check**: The NAPI handler's `channel_open_direct_tcpip()` doesn't evaluate `ForwardingPolicy::check()` at all. It only handles `alknet-` prefixed channels and rejects everything else. This means NAPI-served tunnels have no forwarding access control, defeating the purpose of ADR-031.
The core `ServerHandler` and `SshHandler` both correctly use `IdentityProvider` and `ForwardingPolicy`. The NAPI handler should be consistent.
**Fix**:
- `NapiServerHandler` should hold `Arc<dyn IdentityProvider>` and use it in `auth_publickey()`
- `NapiServerHandler.auth_publickey()` should call `identity_provider.resolve_from_fingerprint()` and store the resulting `Identity`
- `NapiServerHandler.channel_open_direct_tcpip()` should evaluate `ForwardingPolicy::check()` with the identity before proxying, matching `ServerHandler` and `SshHandler` behavior
## Acceptance Criteria
- [ ] `NapiServerHandler` holds `Arc<dyn IdentityProvider>` and `Arc<ArcSwap<DynamicConfig>>`
- [ ] `auth_publickey()` delegates through `IdentityProvider::resolve_from_fingerprint()` and stores `Identity` on the session
- [ ] `channel_open_direct_tcpip()` evaluates `ForwardingPolicy::check()` before proxying
- [ ] Per-identity forwarding rules work correctly through NAPI
- [ ] Existing NAPI tests pass
- [ ] New test: forwarding policy deny blocks channel open via NAPI handler
## References
- crates/alknet-napi/src/serve.rs — NapiServerHandler to be fixed
- crates/alknet-core/src/server/handler.rs — correct pattern to follow
- docs/architecture/identity.md — IdentityProvider contract
- docs/architecture/decisions/031-forwarding-policy.md — ForwardingPolicy
## Notes
> Identified during Phase 1 review (W1)
## Summary
> To be filled on completion

View File

@@ -0,0 +1,49 @@
---
id: cleanup/non-exhaustive-public-api
name: Add #[non_exhaustive] to public API enums and structs likely to evolve
status: pending
depends_on:
- review/phase1-core-modifications
scope: narrow
risk: low
impact: component
level: implementation
---
## Description
Several public API types introduced in Phase 1 are likely to gain variants or fields in future phases. Adding `#[non_exhaustive]` now prevents downstream breakage when new variants/fields are added.
**Types to annotate**:
- `ForwardingAction` — may gain new actions beyond Allow/Deny
- `TargetPattern` — may gain new pattern types
- `OperationType` — may gain new operation kinds
- `InterfaceConfig` — will gain new interface types (HTTP/WS, DNS)
- `ForwardingRule` — may gain new matching fields
- `DynamicConfig` — will gain new sections
- `CallError` — may gain new fields
**Note**: `TransportKind` already has `Dns` and `WebTransport` as tags-only and is likely to gain variants too, but it may already be exhaustively matched in some code. Check first before annotating.
## Acceptance Criteria
- [ ] `#[non_exhaustive]` added to enums/structs listed above
- [ ] All match statements on these types updated with wildcard arms where needed
- [ ] All existing tests pass
- [ ] No new warnings from clippy
## References
- crates/alknet-core/src/config/forwarding.rs — ForwardingAction, TargetPattern, ForwardingRule
- crates/alknet-core/src/call/spec.rs — OperationType
- crates/alknet-core/src/interface/mod.rs — InterfaceConfig
- crates/alknet-core/src/config/dynamic_config.rs — DynamicConfig
- crates/alknet-core/src/call/response.rs — CallError
## Notes
> Suggested during Phase 1 review (S1)
## Summary
> To be filled on completion

View File

@@ -0,0 +1,43 @@
---
id: cleanup/panic-free-static-config
name: Replace panic/expect/unwrap with Result-based error handling in StaticConfig
status: pending
depends_on:
- review/phase1-core-modifications
scope: narrow
risk: low
impact: component
level: implementation
---
## Description
The `parse_proxy_config` function and related code in `crates/alknet-core/src/config/static_config.rs` uses `expect()`, `panic!()`, and bare `unwrap()` calls. This is bad form for production code — panics in library code should be avoided unless truly unreachable.
Since `StaticConfig::from_serve_options()` already returns `Result<..., ConfigError>`, the proxy config parsing should propagate errors through the `Result` chain instead of panicking. A misconfigured proxy string should produce a clear `ConfigError`, not crash the process.
**Fix**:
- Replace `expect()` and `panic!()` in `parse_proxy_config` with proper `Result::Err` returns
- Replace bare `unwrap()` calls with `?` or explicit error mapping
- Ensure all error paths produce meaningful `ConfigError` variants
## Acceptance Criteria
- [ ] No `panic!()`, `expect()`, or bare `unwrap()` in `static_config.rs` production code paths
- [ ] All error paths return `Result<..., ConfigError>` with descriptive messages
- [ ] Invalid proxy config strings produce clear errors instead of panicking
- [ ] All existing tests pass
- [ ] New test: malformed proxy string returns `Err(ConfigError)`, doesn't panic
## References
- crates/alknet-core/src/config/static_config.rs — lines with panic/expect/unwrap
- crates/alknet-core/src/error.rs — ConfigError type
## Notes
> Identified during Phase 1 review (W5)
## Summary
> To be filled on completion

View File

@@ -0,0 +1,41 @@
---
id: cleanup/ssh-session-recv-stub-doc
name: Document SshSession::recv() stub as planned future work
status: pending
depends_on:
- review/phase1-core-modifications
scope: single
risk: trivial
impact: isolated
level: implementation
---
## Description
`SshSession::recv()` and `send()` in `crates/alknet-core/src/interface/ssh.rs` are stubs — `recv()` unconditionally returns `None` and `send()` returns `Ok(())`. Per the architecture spec (interface.md), the `alknet-control:0` channel should eventually route to call protocol events through this interface.
This is acceptable for Phase 1 (tunnel functionality still works via the existing `ServerHandler`), but it should be documented as planned future work so it doesn't get forgotten.
**Fix**:
- Add doc comment on `SshSession::recv()` and `send()` explicitly marking them as stubs
- Note that call protocol event bridging from SSH channels is planned for Phase 2/3
- Add `// TODO:` or similar marker
## Acceptance Criteria
- [ ] `SshSession::recv()` has doc comment stating it's a stub for Phase 1
- [ ] `SshSession::send()` has doc comment stating it's a stub for Phase 1
- [ ] Comment references call protocol integration as planned future work
## References
- crates/alknet-core/src/interface/ssh.rs — recv() and send() stubs
- docs/architecture/interface.md — alknet-control:0 channel routing to call protocol
## Notes
> Identified during Phase 1 review (W3)
## Summary
> To be filled on completion

View File

@@ -1,7 +1,7 @@
--- ---
id: review/phase1-core-modifications id: review/phase1-core-modifications
name: Review Phase 1 core modifications — config split, identity, forwarding, OperationEnv, interface abstraction name: Review Phase 1 core modifications — config split, identity, forwarding, OperationEnv, interface abstraction
status: pending status: completed
depends_on: depends_on:
- core/ssh-interface-extraction - core/ssh-interface-extraction
- core/operationenv-local-dispatch - core/operationenv-local-dispatch
@@ -55,8 +55,8 @@ Review the Phase 1 core modifications after all implementation tasks are complet
## Notes ## Notes
> To be filled by review agent > Review completed by code-reviewer agent. All 13 checklist items passed. 5 warnings identified (W1: NAPI bypasses IdentityProvider = functional bug with cleanup task created; W2: task notes unfilled = by design; W3: SshSession::recv() stub = documented as future work with cleanup task; W4: ServerAuthConfig bridge = acceptable transition debt; W5: panic/unwrap in StaticConfig = code smell with cleanup task created). 4 non-blocking suggestions also generated cleanup tasks.
## Summary ## Summary
> To be filled on completion Phase 1 core modifications approved with minor changes recommended. 385 tests pass, all feature flags compile, clippy clean. All ADRs 026-034 correctly reflected. Main concern: NAPI handler bypasses IdentityProvider/ForwardingPolicy (cleanup task created). 5 cleanup tasks created to address warnings and suggestions before proceeding to Phase 2.