Skip to content
Readiness · Governance

Governance & Lint

A Spectral-style, governance-as-code policy gate over your contract: naming consistency, date-time and enum hygiene, required-field correctness, example coverage, ownership and lifecycle, plus cross-environment policy drift — each finding actionable, each rule enforceable.

Policy gate
Canonical governance · P08
Finding lifecycle and waiver truth
6 active

Active canonical findings

6

Attention actionable

6

Release finding rows

12

Waivers

0 active · 0 expired

Active canonical findings

open 6

  • 3 mutating endpoint(s) have no behavioural scenario

    gov.business.mutation-no-scenario · api/api_orders

    Observed nowmediumopen

    Schema validation does not capture business rules — which input yields which status code or downstream effect. These mutating endpoints have no scenario: POST /orders, PATCH /orders/{id}, POST /orders/{id}/fulfill.

  • Schema ships no example

    gov.examples.schema-no-example · api/api_orders

    Observed nowlowopen

    Schema "OrderItem" (7 fields) has no example payload. Without examples, docs are harder to read and test-data generation is guesswork.

  • Success response has no example

    gov.examples.operation-no-example · operation/ep_api_orders_2

    Observed nowlowopen

    GET /orders/{id} returns 200 but ships no response example. Consumers cannot see the expected shape without calling the live API.

  • Success response has no example

    gov.examples.operation-no-example · operation/ep_api_orders_3

    Observed nowlowopen

    PATCH /orders/{id} returns 200 but ships no response example. Consumers cannot see the expected shape without calling the live API.

  • Success response has no example

    gov.examples.operation-no-example · operation/ep_api_orders_4

    Observed nowlowopen

    POST /orders/{id}/fulfill returns 202 but ships no response example. Consumers cannot see the expected shape without calling the live API.

  • Success response has no example

    gov.examples.operation-no-example · operation/ep_api_orders_1

    Observed nowlowopen

    POST /orders returns 201 but ships no response example. Consumers cannot see the expected shape without calling the live API.

Waiver expiry and reopen truth

No scoped waiver is stored for these findings. Nothing is treated as waived.

Actor: governance-ui-local-owner · role owner · declared unauthenticated. This local declaration is not authenticated approval.

Backend and audit authority: HOLD. No backend identity, authenticated approver, or server audit trail is claimed. Expiry transitions are deterministic local-system events.

84/ 100 ready
Ship ready

6 active finding(s) across 2 categories, under 10 enforced policies.

0critical
0high
1medium
5low
0info
Governance-as-code22 subjects linted Full readiness scorecard
Standardization
API style guides
rule pack 1.0.0revision 1
workspace default
RuleSeverityParameterRemediation
sm-info-complete
Info block is complete
—Give the API a title, version, description and a contact or licence.
sm-op-summary
Operations have a short summary
Add a one-line summary; keep it under the configured length.
sm-op-description
Operations have a description
—Describe what the operation does beyond its summary.
sm-operation-id
operationId present and camelCase
Give every operation a unique operationId in the configured casing.
sm-path-style
Path segments follow one casing
Rename the path segment to the configured casing.
sm-param-style
Parameter names follow one casing
Rename the parameter to the configured casing.
sm-schema-naming
Component schema names are PascalCase
Rename the component to the configured casing.
sm-property-style
Property names follow one casing
Rename the property to the configured casing.
sm-response-4xx
Operations declare a client-error response
—Declare at least one 4xx response so consumers can handle failure.
sm-response-default
Operations declare a default or 5xx response
—Declare `default` or a 5xx response for unexpected failures.
sm-examples
Bodies carry examples
—Add an `example` or `examples` to the media type.
sm-enum-upper
Enum values are SCREAMING_SNAKE
—Rename enum values to SCREAMING_SNAKE_CASE.
sm-no-empty-schema
No empty schemas
—Describe the shape, or remove the empty schema object.
sm-tags-defined
Operation tags are declared at the root
—Declare the tag in the root `tags` array with a description.
sm-server-https
Servers use HTTPS
—Use an https server URL; localhost is exempt.
sm-security-defined
Referenced security schemes exist
—Declare the scheme under securitySchemes, or remove the requirement.
No unsaved changes

The default guide runs for every workspace member, so findings and scores are visible without the editing right. Editing the guide and the cross-project report are the parts that need the higher tier.

Ruleset
10/10 enforced
Policy categories (governance-as-code)
  • Approval integritypass

    A mapping approval was given by someone other than the person who requested it, and still binds the mapping it approved.

  • Naming consistencypass

    Path casing, parameter & property naming, and collection plurality follow one convention.

  • Date-time modellingpass

    Temporal fields use a proper date / date-time format, not free-form strings.

  • Enum governancepass

    Enums use one casing style, declare defaults, and resolve nullability.

  • Required-field correctnesspass

    Path parameters and write bodies declare required fields accurately.

  • Example coverage5

    Operations and schemas ship usable examples for docs and test data.

  • Lifecycle & deprecationpass

    Deprecated endpoints carry a sunset notice; lifecycle is coherent.

  • Ownership & inventorypass

    Every API and endpoint has a named owner — no shadow / orphan surface.

  • Cross-environment policypass

    Auth mode and key-enforcement are consistent across environments.

  • Business-rule governance1

    Mutating / error paths are governed by behavioural scenarios, not just schema.

Lint findings
Governance findings
6
Example coverage5
  • low
    Schema ships no examplegov.examples.schema-no-example

    Schema "OrderItem" (7 fields) has no example payload. Without examples, docs are harder to read and test-data generation is guesswork.

    Fix: Add a representative `example` to "OrderItem" — it doubles as documentation and a scenario / mock seed.
    Pain-point#17#39
  • low
    Success response has no examplegov.examples.operation-no-example/orders

    POST /orders returns 201 but ships no response example. Consumers cannot see the expected shape without calling the live API.

    Fix: Attach at least one example to the success response of POST /orders (a Data Pack or generated mock can seed it).
    Pain-point#17
  • low
    Success response has no examplegov.examples.operation-no-example/orders/{id}

    GET /orders/{id} returns 200 but ships no response example. Consumers cannot see the expected shape without calling the live API.

    Fix: Attach at least one example to the success response of GET /orders/{id} (a Data Pack or generated mock can seed it).
    Pain-point#17
  • low
    Success response has no examplegov.examples.operation-no-example/orders/{id}

    PATCH /orders/{id} returns 200 but ships no response example. Consumers cannot see the expected shape without calling the live API.

    Fix: Attach at least one example to the success response of PATCH /orders/{id} (a Data Pack or generated mock can seed it).
    Pain-point#17
  • low
    Success response has no examplegov.examples.operation-no-example/orders/{id}/fulfill

    POST /orders/{id}/fulfill returns 202 but ships no response example. Consumers cannot see the expected shape without calling the live API.

    Fix: Attach at least one example to the success response of POST /orders/{id}/fulfill (a Data Pack or generated mock can seed it).
    Pain-point#17
Business-rule governance1
  • medium
    3 mutating endpoint(s) have no behavioural scenariogov.business.mutation-no-scenario

    Schema validation does not capture business rules — which input yields which status code or downstream effect. These mutating endpoints have no scenario: POST /orders, PATCH /orders/{id}, POST /orders/{id}/fulfill.

    Fix: Author at least one scenario (happy-path + a validation/error path) per mutating endpoint so business behaviour is governed, not just the schema shape.
    Pain-point#6#5#8