Feature/001 logs linter

[rTexty]

This pull request scaffolds the repository for the logsLinter Go analyzer project, establishing initial project structure, development tooling, repository automation, and documentation. The changes set up code linting, CI workflows, issue templates, and essential configuration files to support development and contribution best practices.

Repository automation and CI/CD setup:

• Added GitHub Actions workflows for continuous integration (ci.yml), workflow linting (actionlint.yml), CodeQL security analysis (codeql.yml), and dependency review (dependency-review.yml). Dependabot is configured to track Go modules and GitHub Actions dependencies. [1] [2] [3] [4] [5]
• Introduced .golangci.repo.yml and .golangci.yml for repository and custom linter configuration, and .custom-gcl.yml to register the custom logsLinter plugin. [1] [2] [3]

Development and contribution guidelines:

• Added comprehensive documentation, including a detailed README.md with project goals, planned rules, and development instructions, as well as a SECURITY.md and a GitHub branch protection/ruleset recommendation document. [1] [2] [3]
• Established issue and pull request templates, and set up code ownership. [1] [2] [3] [4] [5]

Project structure and configuration:

• Created the Go module (go.mod) and entrypoint for the analyzer (cmd/logslinter/main.go). [1] [2]
• Added editor configuration for consistent formatting.

These changes provide a solid foundation for developing, testing, and maintaining the logsLinter analyzer in a collaborative and automated environment.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[Copilot]

Pull request overview

Scaffolds the logsLinter Go analyzer repository with an initial analyzer skeleton, rule/extraction logic (with tests), and baseline repo automation (CI, security scanning, dependency review, templates, and docs) to support ongoing development.

Changes:

• Added initial analyzer package (internal/analyzer) with message extraction + rule checks and accompanying unit tests.
• Added CLI entrypoint (cmd/logslinter) and initialized the Go module and dependencies.
• Introduced repo automation/tooling: GitHub Actions workflows, Dependabot, golangci-lint configs, templates, and security/docs files.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
internal/analyzer/analyzer.go	Defines exported analysis.Analyzer scaffold and Run hook.
internal/analyzer/extract.go	Implements AST-based extraction of literal/concatenated log message strings.
internal/analyzer/extract_test.go	Unit tests for message extraction behavior.
internal/analyzer/rules.go	Defines rule IDs/messages and rule evaluation/check implementations.
internal/analyzer/rules_test.go	Unit tests covering the initial rule behaviors.
cmd/logslinter/main.go	Wires analyzer into a singlechecker CLI binary.
go.mod	Initializes module + Go version + dependencies.
go.sum	Adds dependency checksums.
README.md	Project overview, goals, planned rules, and dev commands.
SECURITY.md	Security reporting policy and expectations.
docs/github-ruleset.md	Suggested GitHub ruleset and required checks.
.golangci.repo.yml	Repo lint configuration for CI (vet/staticcheck/etc + gofmt).
.golangci.yml	End-user golangci-lint config enabling the custom linter plugin.
.custom-gcl.yml	Local custom golangci-lint build/plugin registration config.
.editorconfig	Formatting defaults for Go/Markdown/YAML and Makefiles.
.gitignore	Ignores build outputs and local tooling/context artifacts.
.github/workflows/ci.yml	CI for formatting, vet, test, build, and repo linting.
.github/workflows/actionlint.yml	Lints GitHub Actions workflows.
.github/workflows/codeql.yml	CodeQL analysis workflow for Go.
.github/workflows/dependency-review.yml	Dependency review workflow for PRs.
.github/dependabot.yml	Dependabot configuration for Go modules and GitHub Actions.
.github/pull_request_template.md	PR template with verification/checklist items.
.github/ISSUE_TEMPLATE/bug_report.yml	Bug report issue template.
.github/ISSUE_TEMPLATE/feature_request.yml	Feature request issue template.
.github/ISSUE_TEMPLATE/config.yml	Issue template config + security contact link.
.github/actionlint.yaml	actionlint configuration.
.github/CODEOWNERS	Establishes default code ownership.

---

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

[Copilot]

Local custom-golangci-lint is pinned to v2.11.2, while CI runs golangci-lint v2.1. If both are meant to be used for the same checks, this drift can cause "works locally, fails in CI" behavior; consider pinning a single version or documenting why they differ.

[Copilot]

CI pins golangci-lint to v2.1, but .custom-gcl.yml pins the local custom binary to v2.11.2. Consider keeping these versions in sync (or documenting the reason for divergence) to avoid inconsistent lint results between local runs and CI.

[Copilot]

The module path uses mixed case (github.com/rTexty/logsLinter). Go module paths are case-sensitive, and mixed-case paths can lead to confusing import / go get mismatches (especially on case-insensitive filesystems). Consider switching the module path to all-lowercase to avoid these issues long-term.

[Copilot]

README describes the project as "Production-ready", but the analyzer Run currently returns nil, nil and the Status section says the repo is still being scaffolded. Consider adjusting the top-level description to avoid setting incorrect expectations until the analyzer is functional.

[Copilot]

The go directive includes a patch version (go 1.24.0), but go.mod only allows major.minor (e.g., go 1.24). As written, go mod / go test will fail to parse the module file.

[Copilot]

README states the project requires Go 1.23+, but go.mod targets Go 1.24 (and CI uses go-version-file: go.mod). Align the documented minimum Go version with the module/tooling so contributors don't use an unsupported version.

[Copilot]

msgLowercaseStart says the message "must start with a lowercase letter", but the rule implementation intentionally allows non-letter prefixes (e.g., digits) and empty strings. This makes diagnostics misleading; consider rewording to something like "if the message starts with a letter, it must be lowercase" (or tighten the rule to match the current wording).

[Copilot]

msgNoSpecialChars claims the message must not contain special characters or emoji, but checkNoSpecialCharsOrEmoji only checks for !, ..., and a trailing ? (plus emoji). Either broaden the check to match the message or narrow the message so users understand what's actually prohibited.