sdlc.yaml schema

Reference for every field in sdlc.yaml. See Concepts — sdlc.yaml for how config propagates through LaneSync.

Source and syntax

Independent repositories store sdlc.yaml at their root. Organization setup stores it at <org>/.github/sdlc.yaml; optional local files customize supported fields only when the central setting permits it. See Configure an organization for the exact inheritance rules. Use YAML 1.2. Duplicate keys, unknown fields, invalid types, unsupported versions, custom tags, aliases, anchors, and YAML merge keys are rejected with source diagnostics. Legacy stage-at-root documents remain supported through an explicit adapter; do not mix root stages with stages:. Omission and {} inherit. Explicit [], false, 0, and nullable null are preserved. Defaults apply after inheritance. Organization minimums cannot be removed by a local value.

Organization control

organization.allow_repository_customization is a boolean, defaults to false, and may appear only in the central .github configuration. Repository files cannot enable customization or change enrollment scope.

Release naming

release_naming is a mapping with:

format: semver-v-strict, semver-plain, semver-v-prerelease, semver-plain-prerelease, semver-loose-major, calver-YYYY-MM-DD, calver-YYYY-MM, calver-YY-MM, train-YYYY-Qn, or custom.
mapping: R1 mirrors the milestone title; R2 adds v; R3 removes a leading v.
custom_regex: a valid regular expression when format: custom; otherwise optional and nullable.

Release naming remains organization-controlled for covered repositories. The wizard explicitly reviews migration from older database-only naming settings.

Approval requirements and automation

Development, testing, and evidencing support required_reviewers.min_approvals, an integer from zero to six, defaulting to one. Local values must meet or exceed organization minimums. Eligible required_reviewers.teams are supported for evidence review and remain organization-controlled; development and testing approvals use GitHub’s pull request approval rules. stages.development.auto_create_branch_on_assign and stages.testing.auto_cut_release_branch are booleans, defaulting to false. Repositories may customize them; enabling automation does not bypass stage gates.

Top level

version

Type: string Required: No; defaults to v1 Value: v1 (current schema version)

name

Type: string Required: No Description: Display name for the repository in LaneSync and reports.

stages

Type: object Required: Yes Keys: planning, development, testing, evidencing, deployment

features

Type: array Required: No Description: Test file glob patterns mapped to external feature IDs for quality tracking.

features:
  - pattern: "src/__tests__/auth*"
    system: github
    external_id: "42"

quality_gates

Type: object Required: No Description: Optional thresholds for the Quality scorecard Gate Verdict (GO / NO-GO). LaneSync compares uploaded CI evidence against these values. Omit a field (or the whole block) to skip that comparison — LaneSync never invents defaults.

quality_gates:
  coverage:
    min_line_percent: 80
  security:
    max_critical: 0
    max_high: 5
    max_medium: 20
  sast_scan:
    max_critical: 0
    max_high: 0
    max_medium: 10

Sub-key	Maps to evidence
`coverage.min_line_percent`	`metrics.coverage.line_percent`
`security.max_*`	`metrics.security.vulnerabilities`
`sast_scan.max_*`	`metrics.sast_scan.vulnerabilities`

Wizard defaults (pre-filled unless cleared): 80% line coverage; security 0/0/20 (critical/high/medium); SAST 0/0/10. See Configure sdlc.yaml — Quality gates.Configure during the repo setup wizard Quality gates step, or edit manually after bootstrap.

stages.planning

Field	Type	Default	Description
`require_milestone`	boolean	—	Milestone must exist in GitHub
`require_issues_assigned`	boolean	—	All milestone issues need assignees

stages.development

Field	Type	Description
`branch`	string	Trunk branch (usually `main`)
`deploy_target`	string	Logical deploy environment label (e.g. `dev`)
`required_checks`	string[]	GitHub Actions check names — must match job names exactly

Development blocking = check in required_checks AND conclusion = failure. Do not expect non-listed workflows to block the stage.

stages.testing

Field	Type	Description
`branch_pattern`	string	Glob for release branch (e.g. `release/` or `release/*`)
`deploy_target`	string	Staging environment label
`required_checks`	string[]	Checks evaluated on release branch (or trunk in trunk-based mode)

stages.evidencing

Field	Type	Description
`required_reviewers.min_approvals`	number	Minimum approving reviews
`required_reviewers.teams`	string[]	GitHub team slugs eligible to approve

stages.deployment

Field	Type	Description
`target`	string	Production target label (e.g. `production`)
`tag_pattern`	string	Optional GitHub tag glob; omission protects all tags, including date and train releases. Organization-controlled.
`promotion`	string	`manual` or automated promotion mode
`requires_evidence_approval`	boolean	Block deploy until evidence PR approved

Canonical example

version: v1
name: my-app

quality_gates:
  coverage:
    min_line_percent: 80
  security:
    max_critical: 0
    max_high: 5
    max_medium: 20
  sast_scan:
    max_critical: 0
    max_high: 0
    max_medium: 10

stages:
  planning:
    require_milestone: true
    require_issues_assigned: true

  development:
    branch: main
    deploy_target: dev
    required_checks:
      - CI — Build & Test

  testing:
    branch_pattern: "release/*"
    deploy_target: staging
    required_checks:
      - CI — Build & Test

  evidencing:
    required_reviewers:
      min_approvals: 1

  deployment:
    target: production
    promotion: manual
    requires_evidence_approval: true

LaneSync repo example

The LaneSync product repository uses this configuration:

version: v1
name: sdlc-state

stages:
  planning:
    require_milestone: true
    require_issues_assigned: true

  development:
    branch: main
    deploy_target: dev
    required_checks:
      - "Unified CI — Build & Push"

  testing:
    branch_pattern: "release/**"
    deploy_target: staging
    required_checks:
      - "Unified CI — Build & Push"
      - "Deploy App to AWS (DB + Compose)"

  evidencing:
    required_reviewers:
      min_approvals: 1
      teams:
        - engineering-leads

  deployment:
    target: production
    promotion: manual
    requires_evidence_approval: true

Check names are repository-specific. Copy structure, not check names, when configuring your own repo.

Get Started

Concepts

Guides

Dashboard

Reference

Enterprise

Source and syntax

Organization control

Release naming

Approval requirements and automation

Top level

stages.planning

stages.development

stages.testing

stages.evidencing

stages.deployment

Canonical example

LaneSync repo example

​Source and syntax

​Organization control

​Release naming

​Approval requirements and automation

​Top level

​stages.planning

​stages.development

​stages.testing

​stages.evidencing

​stages.deployment

​Canonical example

​LaneSync repo example

​Related

Source and syntax

Organization control

Release naming

Approval requirements and automation

Top level

stages.planning

stages.development

stages.testing

stages.evidencing

stages.deployment

Canonical example

LaneSync repo example

Related