feat: transparency manifest — attested 'what this tool read' section (#55) - #67
Merged
Conversation
…ion (#55) Adds counting middleware at the HTTP RoundTripper level that classifies every outgoing request by registered route class (REST or GraphQL). The manifest is extracted after each fetch and stamped into the report schema as 'access_manifest', rendered as a plain-language 'What this tool read' section. Files changed: - provider/manifest.go (new): CountingTransport, RouteTable, Manifest types; GitHub/GitLab route tables and static never-requested lists - provider/provider.go: added AccessManifest field to ActivitySet - provider/github/github.go: adapter uses CountingTransport, populates manifest after FetchActivity - provider/gitlab/gitlab.go: same as GitHub, with /api/v4 strip prefix - report/report.go: AccessManifest/EndpointCount types; WithAccessManifest BuildOption; buildAccessManifest helper; Build() stamps the manifest - render/render.go: classLabel template function for plain-language names - render/templates/sections/60-transparency.tmpl (new): renders the transparency section with endpoint table and never-requested list - render/testdata/sample-report.json: added access_manifest block to fixture - provider/parity_test.go: zero out platform-specific AccessManifest - docs/employer-onepager.md: added 'What data did the tool access?' section - provider/manifest_test.go (new): AC-1 through AC-8 acceptance tests - report/manifest_test.go (new): round-trip, backward compat, local run tests - render/transparency_test.go (new): rendering tests, prohibited-strings, golden file compatibility Key decisions: - CountingTransport wraps http.RoundTripper, not http.Client, so it intercepts all requests transparently through the default transport - Route patterns use {*}-style wildcards to handle URL-encoded repo paths (GitLab %2F decoded by Go's HTTP client) - Manifest() locks the transport after read to prevent post-fetch requests from skewing counts - never_requested is a static slice per adapter, not generated dynamically - Patterns like /projects/{*}/merge_requests handle variable-depth project paths correctly Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #55
Implemented by the autonomous loop: DA (deepseek/deepseek-v4-flash) → deterministic gate (test, vet, fmt) → QAA (anthropic/claude-haiku-4.5) approved.