Add GitHub Copilot review instructions

[aryanmehrotra]

Summary

Add comprehensive GitHub Copilot code review instructions tailored to the GoFr framework.

What's Included

Framework-Specific Context

• Key directories, module info, CI matrix (Go 1.23-1.25)
• Framework vs service distinction — every change affects downstream users

Core Principles (from CONTRIBUTING.md)

• No globals, no init — gochecknoglobals / gochecknoinits enforced
• Lean interfaces — consumer defines, take exactly what you need
• Dependencies as parameters — no os.Getenv(), no singletons
• Context always first, custom key types only

Error Handling Reference

• Full error type table with HTTP status codes and log levels
• ErrorEntityNotFound (404/INFO), ErrorInvalidParam (400/INFO), ErrorServiceUnavailable (503/ERROR), etc.
• Rules: implement StatusCode() + LogLevel(), wrap with context (err113), don't double-log

Go Proverbs & Idiomatic Principles

• Rob Pike's Go Proverbs applied as actionable review rules
• Clarity > cleverness, errors are values, bigger interface = weaker abstraction
• Concurrency rules: know how goroutines stop, channels orchestrate, mutexes serialize
• Code organization: return early, avoid stuttering, name length proportional to scope
• Error strings lowercase without punctuation

Linting Requirements

• Full table from .golangci.yml: 45+ linters, funlen (100/50), gocyclo (10), lll (140), American English
• Every //nolint must specify linter + explanation

Testing, API Compatibility, Documentation

• testify + uber-go/mock, table-driven tests, no coverage decrease
• Semver, godoc mandatory, response envelope is public contract
• Code changes require doc updates, examples must stay working

[Copilot]

Pull request overview

Adds a GitHub Copilot instruction document to standardize code review expectations for GoFr contributions, with framework-specific guidance around API stability, error handling, linting, testing, and idiomatic Go practices.

Changes:

• Introduces a comprehensive GoFr-focused code review guideline document for Copilot.
• Documents repo context (module, Go versions, key directories) and key architectural principles (no globals/init, lean interfaces, context-first).
• Provides references for error handling, logging, linting, testing, and documentation expectations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coolwednesday]

The instructions look okay to begin with. However currently the rules are written keeping REST as primary focus. Need to be extended for other Modules also. Bu would like to have that iteratively. Hence this PR looks god to me.

[Umang01-hash]

1. In section 1 we missed the Multi-module architecture in GoFr like our datasources having their own go.mod. Any reviewer who doesn't know this will:

• Miss dependency changes in datasource PRs
• Incorrectly assume a dependency change in one datasource affects the core module
• Miss when a datasource PR needs its own version bump

We should include Multi-module repo. Every pkg/gofr/datasource/*/ subdirectory that contains a go.mod is a separate Go module. Changes to a datasource's dependencies are scoped to that module only. PRs touching multiple modules need each module's go.sum updated independently.

[Umang01-hash]

It should be: Go: 1.25 (minimum in go.mod; CI compatibility-tests on 1.23, 1.24, 1.25)

The go.mod says go 1.25.0, so the minimum is 1.25. The CI matrix tests on older versions for compatibility verification.

[Umang01-hash]

The 5-point feedback structure has API Impact, Correctness, Performance, Testing, Documentation — but no observability point. For a framework that markets "built-in observability" this is a glaring omission. Lets add:

Observability: Does the change include proper OTel spans? New datasource operations should have traces. New pub/sub backends must follow the tracing pattern. Metrics should
  be registered for any new operation that has latency/error characteristics.

[Umang01-hash]

These are missing from the key directories list:

• pkg/gofr/datasource/pubsub/ — PubSub backends (most active area)
• pkg/gofr/service/ — HTTP service-to-service clients with tracing
• pkg/gofr/datasource/file/ — File store abstractions

[Umang01-hash]

Correct Go idiom and GoFr's own convention is "return concrete types." A concrete type includes a pointer to a struct (*MyType), a slice, a map. "Return structs" is technically narrower and wrong in many cases. Change to "return concrete types."

[Umang01-hash]

Can we add some examples here like : PUBSUB_BACKEND, TRACE_EXPORTER, HTTP_PORT