Verify and close resolved GitHub issues #91 (root-level arrays) and #94 (field name casing) with documentation comments explaining how existing features cover these use cases.

Purpose: Clean up the issue tracker so Phase 1 is complete. Both issues are already solved by existing features -- #91 by the (sebuf.http.unwrap) = true annotation on repeated fields, and #94 by proto3's built-in json_name field option. Closing them with proper documentation prevents future confusion.

Output: Both issues closed on GitHub with explanatory comments.

<execution_context> @/Users/sebastienmelki/.claude/get-shit-done/workflows/execute-plan.md @/Users/sebastienmelki/.claude/get-shit-done/templates/summary.md </execution_context>

@.planning/PROJECT.md @.planning/ROADMAP.md @.planning/STATE.md @.planning/phases/01-foundation-quick-wins/01-RESEARCH.md Task 1: Close issue #91 (root-level arrays) with documentation (no files modified -- GitHub issue management only) Close GitHub issue #91 with a detailed comment explaining that the existing `(sebuf.http.unwrap) = true` annotation already provides root-level array support.

Step 1: Verify the existing implementation by confirming these files exist:

  • internal/httpgen/testdata/proto/unwrap.proto -- contains RootRepeatedResponse test message (lines 91-95)
  • internal/httpgen/unwrap.go -- contains generateRootRepeatedUnwrapMarshalJSON and generateRootRepeatedUnwrapUnmarshalJSON
  • internal/httpgen/unwrap_test.go -- contains TestRootUnwrapFileGeneration with RootRepeatedResponse subtest

Step 2: Close the issue with the exact comment below:

gh issue close 91 --comment "$(cat <<'COMMENT'
This is already supported via the existing `(sebuf.http.unwrap) = true` annotation on repeated fields. No new annotation is needed.
 
**Usage:**
\`\`\`proto
message ListItemsResponse {
  repeated Item items = 1 [(sebuf.http.unwrap) = true];
}
\`\`\`
 
**Result:** The response serializes as `[{...}, {...}]` instead of `{"items": [{...}, {...}]}`.
 
The implementation generates custom `MarshalJSON`/`UnmarshalJSON` methods on the response message that marshal/unmarshal the repeated field directly at the root level.
 
**Test coverage:**
- Proto fixture: `internal/httpgen/testdata/proto/unwrap.proto` (`RootRepeatedResponse` message)
- Implementation: `internal/httpgen/unwrap.go` (`generateRootRepeatedUnwrapMarshalJSON`, `generateRootRepeatedUnwrapUnmarshalJSON`)
- Tests: `internal/httpgen/unwrap_test.go` (`TestRootUnwrapFileGeneration`)
 
**Documentation:** See the "Root-level unwrap" section in CLAUDE.md for full examples including root repeated, root map, and combined unwrap patterns.
 
This works across all generators: go-http (server marshal/unmarshal), go-client (same marshaling), and openapiv3 (array schema at root level).
COMMENT
)"
```bash # Verify issue is closed gh issue view 91 --json state,comments | jq '.state' # Should output: "CLOSED" ``` - Issue #91 state is CLOSED - Closing comment documents the `(sebuf.http.unwrap) = true` syntax with proto example - Closing comment shows expected JSON output (`[{...}, {...}]` vs `{"items": [...]}`) - Closing comment references test files (`unwrap.proto`, `unwrap.go`, `unwrap_test.go`)
Task 2: Verify issue #94 (field name casing) is properly closed (no files modified -- GitHub issue verification only) Verify that GitHub issue #94 is already closed with adequate documentation.

Step 1: Check issue state:

gh issue view 94 --json state,comments

Expected state: CLOSED (confirmed during research -- closed by @SebastienMelki with comment explaining proto3's json_name as the existing solution).

Step 2: If the issue is already closed with a thorough comment (which research confirms), no further action is needed. Simply log confirmation.

Step 3: If for any reason the issue is NOT closed or the comment is insufficient, close it with the exact comment below:

gh issue close 94 --comment "$(cat <<'COMMENT'
Closing -- proto3's built-in \`json_name\` field option provides per-field JSON name override:
 
\`\`\`proto
message User {
  string first_name = 1 [json_name = "firstName"];  // camelCase in JSON
  string last_name = 2 [json_name = "LastName"];     // PascalCase in JSON
  string user_id = 3;                                // defaults to "userId" per proto3 spec
}
\`\`\`
 
For global snake_case output, use \`protojson.MarshalOptions{UseProtoNames: true}\` when marshaling.
 
See https://protobuf.dev/programming-guides/proto3/#json for the proto3 JSON mapping specification.
 
No sebuf-specific annotation is needed -- this is handled entirely by proto3 and protojson.
COMMENT
)"

This should be a no-op since issue #94 is already closed with a detailed comment from the repo owner.

# Verify issue is closed
gh issue view 94 --json state | jq '.state'
# Should output: "CLOSED"
 
# Verify closing comment exists and mentions json_name
gh issue view 94 --json comments | jq '.comments[0].body' | grep -q "json_name"
- Issue #94 confirmed CLOSED - Closing comment adequately documents proto3 `json_name` field option as the existing solution - Comment includes proto example showing per-field overrides and references protobuf.dev docs
After both tasks complete:
  1. gh issue view 91 --json state returns "CLOSED"
  2. gh issue view 94 --json state returns "CLOSED"
  3. Issue #91 closing comment references (sebuf.http.unwrap) = true with proto example showing repeated Item items = 1 [(sebuf.http.unwrap) = true]
  4. Issue #94 closing comment references proto3 json_name field option with proto example and protobuf.dev link

<success_criteria>

  • GitHub issue #91 is closed with a comment documenting how existing unwrap annotation covers root-level arrays
  • GitHub issue #94 is confirmed closed with a comment documenting proto3 json_name as the existing solution
  • No code changes needed -- these are purely issue tracker housekeeping </success_criteria>
After completion, create `.planning/phases/01-foundation-quick-wins/01-02-SUMMARY.md`