feat: Phase 0 — Repository infrastructure, GHAS, GitHub Flow, awesome-copilot assets

[devartifex]

Description

Complete Phase 0 of the master implementation plan: repository infrastructure, security automation, GitHub Flow enforcement, and awesome-copilot asset adoption.

Closes #69, #70, #71, #72, #73, #74, #75, #76, #77, #78, #79, #80, #86, #87, #88

What's Included

🔒 GHAS & Security

• CodeQL code scanning workflow (weekly + PR)
• Secret scanning setup script
• SECURITY.md updated

🔄 GitHub Flow

• Enhanced CI with Playwright E2E + conventional commit check
• Branch protection setup script
• Release-please workflow for semantic versioning
• CODEOWNERS file

📋 Templates & DX

• YAML issue forms (bug, feature, SDK feature)
• Enhanced PR template with security checklist
• PR auto-labeler (10 path-based labels)
• Stale management workflow
• 4 Copilot prompt files

🤖 Awesome-Copilot Assets

• 4 skills: github-issues, doublecheck, copilot-spaces, automate-this
• 6 agents: 4.1-Beast, critical-thinking, implementation-plan, refine-issue, polyglot-test-generator, adr-generator
• 2 instructions: code-review-generic, performance-optimization
• 2 workflows: codespell, check-pr-target

📝 Documentation

• Rewritten copilot-instructions.md (accurate counts, testing sections, skills system)

Type of Change

• ✨ New feature
• 🔧 CI/Build/Infrastructure
• 📝 Documentation
• 🔒 Security fix

Testing

• All existing tests pass (npm run test:unit)
• npm run check passes
• npm run build passes
• No secrets or private repo references in code

Security

• No secrets, API keys, or credentials in code
• No references to private repos or internal infrastructure

In general, the problem is fixed by explicitly defining a permissions block either at the top level of the workflow (applying to all jobs) or per job, and restricting GITHUB_TOKEN to the least privileges actually needed. For this workflow, all jobs only need to read the repository contents and upload artifacts; they do not push commits, modify issues, or update pull requests, so contents: read is sufficient as a minimal starting point. Additional scopes (e.g., pull-requests: write) are not required by any of the shown steps.

The single best fix, without changing any existing functionality, is to add a top-level permissions: block right under the name: CI line, specifying contents: read. This will apply to all jobs (check, e2e, commit-lint) because none of them define their own permissions. No other code, steps, or configuration lines need to be altered, and no additional imports or third-party actions are required. The only file to edit is .github/workflows/ci.yml, and the only region to change is the header area at the top of the YAML file, between line 1 (name: CI) and line 3 (on:), where we insert the new permissions block.

Generally, the fix is to add an explicit permissions: block that restricts the GITHUB_TOKEN to the minimum necessary scopes. You can define it at the workflow root so it applies to all jobs, or per-job if different jobs need different scopes. Here, all jobs only read repository contents and upload artifacts, so a single root-level permissions: contents: read (and optionally other read-only scopes if needed) is sufficient.

The single best fix with no behavior change is: in .github/workflows/ci.yml, add a root-level permissions block near the top (e.g., after name: CI or after the on: block) specifying contents: read. None of the shown steps require write access to issues, pull requests, or contents; actions/checkout, actions/setup-node, npm ci, builds, tests, and actions/upload-artifact all function with a read-only GITHUB_TOKEN. No imports or additional methods are required because this is pure YAML configuration.

Concretely:

• Edit .github/workflows/ci.yml.

• Insert:

  permissions:
    contents: read

  at the workflow root, aligned with on: and jobs:, so it applies to every job (check, e2e, and commit-lint).