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)

tasks/cleanup/adr-doc-comments.md

@@ -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

tasks/cleanup/napi-identity-provider-wiring.md

@@ -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

tasks/cleanup/non-exhaustive-public-api.md

@@ -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

tasks/cleanup/panic-free-static-config.md

@@ -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

tasks/cleanup/ssh-session-recv-stub-doc.md

@@ -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