db

package
v0.2.9 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Aug 18, 2026 License: Apache-2.0 Imports: 20 Imported by: 0

Documentation

Overview

Package db is the database-structure sensor (dimension "db"). Unlike the security sensor it does not walk source files: it resolves the configured database.schema_paths from disk (it is the filesystem-side caller, ADR 0014), asks the provider's SchemaParser for a neutral db.Schema, runs the core dbrules over it, and stamps baseline fingerprints. It is honest about NOT measuring: disabled, no schema_paths, or a provider without a schema parser return Measured=false with a note — never a false "clean, 0 findings".

DECLARED GAP — this sensor does NOT apply path criticality. RF-10 weights a finding's severity by its path class (production/test/example) and its wording says "cada finding", but config.PathCriticalityFor has exactly one caller and it is the security sensor. A db finding is schema-scoped: it is located by table and column inside a schema source, so a project-relative glob would classify the schema FILE, not the object the finding is about, and "a test table" is not a question RF-10 answers. The gap is deliberate and open, not an oversight: see docs/decisions/0070-path-criticality-is-configurable-and-reaches-only-the-security-sensor.md before adding criticality here.

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func OrderingIsProven added in v0.2.9

func OrderingIsProven(dir string) (proven bool, sqlFiles int, err error)

OrderingIsProven reports whether the .sql files sitting AT dir's own level will be ordered by proof rather than by the alphabet, and how many .sql files that level holds.

Proven means: at least one .sql file, and every .sql file at that level carries an integer version flywayVersion matches. One stray name is enough to unprove the whole level, because a name flywayOrderedSQL cannot version lands in its LEXICAL bucket — and from that point the directory's apply order is a fact about the alphabet, not about its contents. golang-migrate's `1_init.up.sql` is the case that matters in practice: `10_x` sorts before `1_init`.

DISCOVERY DEPTH IS NOT READ DEPTH. flywayOrderedSQL reads exactly one level (its own DECLARED LIMIT, ADR 0072), so this reports on exactly one level too. A caller that walks a tree looking for candidate directories may go as deep as it likes; what it must never do is write a path whose schema files live below the level the resolver reads. Answering about one level is how this function keeps the two numbers from being confused.

It re-applies flywayVersion instead of sharing flywayOrderedSQL's loop. That duplication is deliberate — extracting a shared helper would edit sources.go, which this change keeps byte-identical as its ADR 0072 evidence — and it is LOCKED by TestOrderingIsProven_AgreesWithTheResolversOrdering rather than left to drift. Because the predicate lives here, beside the regex, a future flywayOrderedSQL that learns golang-migrate ordering widens init's strictness automatically and no scaffold line changes.

func ResolveSchemaPath added in v0.2.9

func ResolveSchemaPath(root, path string) ([]providers.SourceFile, error)

ResolveSchemaPath resolves ONE database.schema_paths entry exactly as an audit would, and returns the ordered, DECODED sources it produced.

It delegates to readSchemaSources rather than repeating it, and that is the whole point of the function existing. `codefit init` has to decide whether a directory reconstructs into a schema BEFORE it writes that directory into a config; if it answered that question against its own reader, init-time proof and scan-time behaviour could disagree about the same path — different apply order, or different bytes. Two things in particular are not reproducible by inspection and must come from the real reader: Flyway integer ordering, and the byte-order-mark decode (a UTF-16LE dump reaches a tokenizer as NUL-interleaved bytes and reduces to a schema with zero of everything, without complaining).

A path that does not exist is an ERROR here, as it is at scan time: a misconfiguration is a different fact from "this project has no schema", and collapsing the two is how a typo becomes a clean bill of health.

func StampSurface added in v0.2.4

func StampSurface(surf []findings.SurfaceItem, content map[string][]byte)

StampSurface fills the snippet (from the source line at the item's position), the baseline fingerprint, and the stable id of any surface item that lacks them. It is exported so the MCP adapter can stamp the cross rules' items (produced after Audit) with the SAME discipline the sensor uses on its own — one stamping, no drift (ADR 0029). Idempotent: an item already stamped is untouched.

Types

type Result

type Result struct {
	Measured bool
	Note     string
	Res      findings.SensorResult
	// Schema is the parsed neutral schema, exposed so the MCP adapter can run the
	// code↔schema cross (crossrules) over it WITHOUT re-reading/re-parsing and
	// without importing a provider here (ADR 0029). Nil on a not-measured result.
	// The sensor stays schema-only: it merely returns what it parsed; the cross is
	// orchestrated in the adapter, never here.
	Schema *coredb.Schema
	// SchemaContent is the raw content of the parsed schema files, keyed by path —
	// exposed alongside Schema so the adapter can STAMP the cross rules' items
	// (snippet + fingerprint) the same way the sensor stamps its own, since those
	// items are produced after Audit returns and would otherwise carry no baseline
	// identity (ADR 0029). Nil on a not-measured result.
	SchemaContent map[string][]byte
}

Result is the DB audit outcome, including whether the DB was measured at all. Measured=false with a Note is the honest "not audited" state (disabled, no schema_paths, provider without a schema parser) — distinct from "audited, 0 findings".

type Sensor

type Sensor struct {
	// contains filtered or unexported fields
}

Sensor audits the database structure, driven by a schema parser resolved by the caller from the input's shape (.prisma / .sql — ADR 0018). The rule logic lives in the core (dbrules); the sensor only reads/orders the schema files and stamps identity. It depends on exactly the capability it uses, providers.SchemaParser — not LanguageProvider — so the "no parser" case is a compile-time concern of the adapter, not a runtime branch here.

func New

New builds a DB sensor backed by a schema parser.

func (*Sensor) Audit

func (s *Sensor) Audit(ctx auditctx.AuditContext) (Result, error)

Audit resolves the schema, runs the core DB rules, and stamps fingerprints. It returns Measured=false + a Note (never an error) for the honest not-measured cases; a hard error only for a configured-but-missing schema file or a parse failure — silently skipping those would be the false "all good" codefit exists to catch.

func (*Sensor) Dimension

func (*Sensor) Dimension() findings.Dimension

func (*Sensor) Name

func (*Sensor) Name() string

func (*Sensor) OwnedCategories

func (*Sensor) OwnedCategories() []string

OwnedCategories are the baseline Item categories the DB sensor produces: its finding dimension ("db") plus its per-rule surface categories. They scope the unified baseline (ADR 0019) and must be disjoint from every other sensor's.

The DW-0xx categories are APPENDED from dwrules.OwnedCategories() rather than re-listed here: the DW rules run INSIDE this sensor (design §2f), so their categories are the sensor's, and sourcing them from the rule package means a new DW rule cannot land with its category missing from the baseline scope — the one way to corrupt an existing baseline. This is the deliberate contrast with crossrules, whose categories are unioned in the MCP adapter because the cross runs outside any sensor (ADR 0029).

func (*Sensor) Run

Run adapts Audit to the sensors.Sensor interface (for future aggregate use in scan-all). The standalone tool calls Audit directly to get Measured/Note.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL