161ef94b4f
Check engine pin consistency / Dockerfile / CI pin consistency (push) Successful in 8s
Sirius CI/CD Pipeline / Detect Changes (push) Successful in 23s
Validate Docker Configuration / Validate Docker Compose Configuration (push) Successful in 47s
Sirius CI/CD Pipeline / Build API (${{ matrix.platform }}) (push) Has been cancelled
Sirius CI/CD Pipeline / Build UI (${{ matrix.platform }}) (push) Has been cancelled
Sirius CI/CD Pipeline / Merge Engine Manifest (push) Has been cancelled
Sirius CI/CD Pipeline / Merge API Manifest (push) Has been cancelled
Sirius CI/CD Pipeline / Merge UI Manifest (push) Has been cancelled
Sirius CI/CD Pipeline / Build Engine (${{ matrix.platform }}) (push) Has been cancelled
Sirius CI/CD Pipeline / Build Infra (${{ matrix.service }}, ${{ matrix.platform }}) (push) Has been cancelled
Sirius CI/CD Pipeline / Merge Infra Manifest (sirius-postgres) (push) Has been cancelled
Sirius CI/CD Pipeline / Merge Infra Manifest (sirius-rabbitmq) (push) Has been cancelled
Sirius CI/CD Pipeline / Merge Infra Manifest (sirius-valkey) (push) Has been cancelled
Sirius CI/CD Pipeline / Integration Test (push) Has been cancelled
Sirius CI/CD Pipeline / Public Stack Contract (push) Has been cancelled
Sirius CI/CD Pipeline / Dispatch Demo Deployment (sirius-demo branch) (push) Has been cancelled
Sirius CI/CD Pipeline / Dispatch Demo Canary (main branch) (push) Has been cancelled
Sirius CI/CD Pipeline / Guard Registry Namespace (push) Has been cancelled
2.3 KiB
2.3 KiB
SiriusScan Repository Standards (Advisory v1)
This document defines recommended repository standards for SiriusScan projects.
The goal is consistency and professionalism without introducing blocking rules. Teams can adopt these recommendations incrementally.
Scope
Applies to public SiriusScan repositories, starting with Sirius and then expanding to:
go-apiapp-scannerapp-agentpingppwebsite
Recommended baseline artifacts
Each repository should include:
README.mdCONTRIBUTING.mdSECURITY.mdCODE_OF_CONDUCT.mdLICENSESUPPORT.md(recommended for active external contribution)
Issue and PR intake standards
Recommended defaults:
- Issue templates for bug reports and feature requests
- A security-focused intake path with explicit private-report guidance
- A PR template that captures:
- problem statement
- risk and validation evidence
- docs and rollout notes
For repositories with low issue volume, start with minimal templates and expand later.
Labels and triage hygiene
Recommended label taxonomy:
type:*(for example:type:bug,type:enhancement,type:security)status:*(for example:status:needs-triage,status:blocked,status:ready)sev:*for risk level where relevant- domain labels for components only where maintainers need them
Recommended triage SLA:
- First maintainer response within 2 business days
- Security-labeled issues reviewed as priority
Metadata and discoverability
Each repository should have:
- A one-line description aligned with org voice
- At least 4-6 relevant topics
- A homepage URL to docs, API reference, or website
- Optional Discussions enabled where community interaction is expected
Review and CI expectations (advisory)
Recommended defaults (not hard-gated in this phase):
- At least one maintainer review before merge
- CI should run on pull requests
- Validation evidence included in PR description
- Security-sensitive changes include rollback notes
Adoption approach
- Adopt standards in
Siriusfirst. - Reuse the rollout checklist in
.github/REPO_ROLLOUT_CHECKLIST.md. - Track deviations and repository-specific exceptions in the repo README or maintainer notes.
- Revisit after adoption to decide whether any standards should become required.