[log] Add debug logging to delegation RuntimeConfig

[github-actions]

Summary

Adds debug logging to internal/delegation/config.go, which previously had no logger despite containing meaningful startup validation logic used by both internal/server/unified.go and internal/proxy/proxy.go.

Changes

• Added logConfig logger via logger.ForFile() (namespace delegation:config).
• RuntimeConfig.Validate(): logs each of the four failure branches (nil config, missing store, missing capability, missing state path) plus a success log including statePath and controlListenAddr.
• RuntimeConfig.ControlDeps(): logs when called on a nil config, since that path silently returns a zero value that disables delegation control.

Validation

• go build -o awmg ./... — succeeds
• go vet ./internal/delegation/... — clean
• go test ./internal/delegation/... — passes
• gofmt -l internal/delegation/config.go — no issues

Generated by Go Logger Enhancement · copilot · auto · 54.5 AIC · ⊞ 11.7K · ◷

[Copilot]

🟢 Approval recommended

The change is low-risk and the remaining test-coverage suggestion is a minor nit.

Pull request overview

Adds debug logging for delegation runtime configuration validation and dependency access.

Changes:

• Adds a delegation:config logger.
• Logs validation failures, successful validation, and nil control dependencies.

File summaries

File	Summary
internal/delegation/config.go	Adds runtime configuration diagnostics. Nit: add focused tests for the new logging branches.

Review details

Suppressed comments (1)

internal/delegation/config.go:42

• The existing config tests cover only return values and forwarded dependencies, so none of the new logConfig branches or the success fields are exercised. Since this PR's behavior is the debug diagnostics themselves (and delegation already has dedicated logging tests in selector_logging_test.go, recovery_logging_test.go, and control_handler_logging_test.go), add a focused capture test covering the validation failures, successful validation, and nil ControlDeps() message.

	logConfig.Printf("Delegation runtime config validated: statePath=%s, controlListenAddr=%s", c.StatePath, c.ControlListenAddr)

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

🔒 mcpg Read-Only Stress — default

Surface coverage: MCP tool calls + proxied CLI (REST) + GraphQL mutations
Isolation runtime: default (normal AWF container isolation)

Part	Surface	Op	Result	Expected	Status
A	MCP	reads (list_issues, list_pull_requests, get_file_contents, list_commits)	data returned	ALLOWED	✅
B	MCP	writes (star/issue/comment/branch/file/PR)	tool absent from catalog ("unknown tool") for all targets	BLOCKED	⚠️
C	CLI	reads (same 4 ops via github proxy CLI)	data returned	ALLOWED	✅
D	CLI	REST writes (reaction/star/issue/comment)	gh not authenticated in this job	BLOCKED	⚠️
E	CLI	GraphQL mutations (addReaction/addStar/createIssue)	gh not authenticated in this job	BLOCKED	⚠️

Overall: INCONCLUSIVE

Notes:

• No write leaked in any part — INCONCLUSIVE, not FAIL.
• Part B: the github CLI catalog exposed only 23 read-only tools (list_, get_, search_*, issue_read, pull_request_read). star_repository, issue_write, add_issue_comment, create_branch, create_or_update_file, and create_pull_request were absent entirely, so calls failed with unknown tool rather than a gateway-specific refusal. Per the test's own methodology this only proves gh-aw's GITHUB_READ_ONLY=1 backend config (tools never registered), not mcpg's independent DIFC/guard enforcement layer — recorded as ⚠️ INCONCLUSIVE per spec.
• Part D/E: gh auth status and gh api graphql both returned "set the GH_TOKEN environment variable" — gh is unauthenticated in this job, so REST/GraphQL write probes could not be attempted. Recorded as ⚠️ INCONCLUSIVE per spec (not silently treated as blocked).

🔒 mcpg read-only stress (default AWF runtime) by Read-Only Stress: default runtime

[github-actions]

🔒 mcpg Read-Only Stress — gvisor

Surface coverage: MCP tool calls + proxied CLI (REST) + GraphQL mutations
Isolation runtime: gvisor

Part	Surface	Op	Result	Expected	Status
A	MCP	reads (list_issues, list_pull_requests, get_file_contents, list_commits)	data returned	ALLOWED	✅
B	MCP	writes (add_issue_comment/star_repository/issue_write/create_branch/create_or_update_file/create_pull_request)	all absent from 23-tool catalog (only get_/list_/search_*/issue_read/pull_request_read exposed)	BLOCKED	⚠️
C	CLI	reads (same 4 calls via proxied github binary on PATH)	data returned	ALLOWED	✅
D	CLI	REST writes (gh api)	gh not authenticated in this environment ("not logged into any GitHub hosts"); not attempted	BLOCKED	⚠️
E	CLI	GraphQL mutations (gh api graphql)	same gh unauthenticated blocker; not attempted	BLOCKED	⚠️

Overall: INCONCLUSIVE

No write leaked in this run. Part B write-tool targets are absent from the gateway's exposed catalog entirely (only 23 read-only tools registered — get_commit, get_file_contents, get_label, get_latest_release, get_release_by_tag, get_tag, issue_read, list_branches, list_commits, list_issue_fields, list_issue_types, list_issues, list_pull_requests, list_releases, list_repository_collaborators, list_starred_repositories, list_tags, pull_request_read, search_code, search_commits, search_issues, search_pull_requests, search_repositories), consistent with gh-aw's GITHUB_READ_ONLY=1 backend behavior described in the test plan — this confirms backend/toolset configuration but does not independently exercise mcpg's own gateway-level DIFC/guard write-blocking layer. Parts D/E could not be exercised because gh was unauthenticated in this sandbox, so the token-scope write boundary was not tested this run. Read-only held identically to the default runtime for every probe that was actually reachable.

🔒 mcpg read-only stress (gVisor runtime) by Read-Only Stress: gVisor runtime