light-consistency

Cross-material consistency maintenance

Working mode (always active)

Run in the background during any task that produces materials: each time a material is generated or modified, compare it against the "unified definitions" in project library db09, and correct or flag any deviation found.

Single source of truth: project terminology and definitions table (stored in db09)

Draw on content-strategy's "define first, then produce": all materials derive from one definitions file; downstream components are forbidden from each writing their own.

Two forms of the source of truth (same truth, machine-readable ⊃ human-readable):

Human-readable truth (mandatory for every project)：databases/db09-projects/projects/<项目>/terminology.md——Markdown terminology table (category/standard name/abbreviation/English/notes), maintained by a02, a fixed component of the db09 project card. The audit script reads it to performcoverage gapdetection.
Machine-readable enhancement (generated only when strict validation is needed): three YAML schema templates (assets/ 's db09_glossary.yaml/db09_method_lock.yaml/db09_metric_registry.yaml), with more than Markdown: forbidden/confusable/authoritative value columns, supporting controlled terminology replacement and metric value conflict detection; after expansion, store back in the project db09 directory (alongside terminology.md). See the file list section for the field list.

assets/ The three are blank templates; the real project source of truth always resides in databases/db09-projects/projects/<项目>/, avoiding "db09 pointing to two places".

Maintenance points (lock the wording, in conjunction with the five dimensions of the "Consistency Check Dimensions" below): method/dataset names containing abbreviations are included in the "do-not-change list" (polishing/translation must not replace them); metrics unify symbol + unit + definition (F1 vs F-score); the standard wording of the 3 innovation points is aligned word-for-word across paper/PPT/software copyright/competition; key terms lock Chinese-English correspondence + capitalization and hyphens (fine-tune not written as finetune);Visual specification: if the project has databases/db09-projects/projects/<项目>/palette.json(a visual SSOT instance co-read by paper figures m11/PPT m16/frontend a05), then "cross-material color consistency" directlycheck item by item against that file——the four parties' color picking must be from the same source, and none may start a separate palette; when there is no palette.json, fall back to db05 design_tokens.template.json(DTCG color value anchor source of truth), with paper figures (db07)/PPT (db06)/frontend (db05)/posters all taking one set of values (currently manual/checklist comparison, not script-automated checking）。

Change broadcast: once a definition is modified, immediately trigger arescan of all produced materials, to avoid downstream staleness. The authoritative list of "produced materials" = the union of .light/passport.yaml paths for each stage artifacts: maintained by the orchestrator (§4 artifact ledger); lightweight projects without a passport fall back to the artifacts listed in db09's version_history.md column. Rescanning means running the following item by item over this list consistency_audit.py, and on a hit, fix according to "current state→problem→suggestion".

Audit script: consistency_audit.py

scripts/consistency_audit.py reads the above db09 three-piece set, scans a set of material texts, automatically detects andlocates to 材料:行号 four types of inconsistency, graded by ERROR/WARN, each with "current state → problem → suggestion", and a "count self-check" at the end of the report.

Four types of detection:

SUBSTITUTION Controlled terms/method names are synonymously rewritten or misspelled (case/hyphen/synonym).
METRIC_NAME The same metric is renamed (e.g., writing F1 as "accuracy").
METRIC_VALUE The same metric (same method × dataset) has inconsistent values across materials, or does not match the authoritative db09 value; position-aware, even when multiple metrics/methods are listed side by side on one line, they can be paired nearby without misalignment.
COVERAGE_GAP Standardized terms/metrics appear only in some materials and are absent where they should appear.

Usage (under skills/light-consistency/ ): real audit python scripts/consistency_audit.py --db09 assets --materials <文件...> [--json out.json]; run built-in synthetic materials self-test with no arguments (all four types of detection triggered). Exit code: return 1 if ERROR is found (can be wired into CI), otherwise 0. For an end-to-end example, see examples/worked_example.md。

Consistency audit workflow (inventory → tag → gap → fix)

Borrow the four-step content audit method: ① Inventory extract key claims from each material (method names/metric names + values/innovation wording/chart style) into a list; ② Tag mark each item as consistent/conflicting/missing, with conflicts pointing to specific locations (chapter/page/line); ③ Gap quantify coverage (which contribution points are absent from the PPT, which metric appears only in the paper); ④ Fix for each item give "current state → problem → unified suggestion → revised text".Completeness enforcement: list all items in full without ellipses, and self-check at the end of the report that "number of list items = number of items actually processed".

Consistency check dimensions (five dimensions + logical thread)

①Terminologythe same concept uses the same name throughout; ②Metricsnames/definitions/values are the same everywhere (paper table = PPT figure = abstract numbers); ③Innovation pointsthe statements in the abstract/introduction/conclusion/PPT/application form do not contradict each other; ④Method/dataset namesnot renamed midway; ⑤Visualpaper figures/PPT/frontend/poster share the same design language (manual/checklist comparison: if the project has databases/db09-projects/projects/<项目>/palette.json then compare against it item by item to check whether the colors used in the four parties come from the same source; if not, check according to db05 design_tokens.template.json ; the script only checks text-based items, visual depends on assets/design_language_extract.template.md manual sign-off); ⑥Logical threadthe paper narrative and PPT narrative, and the software copyright functionality and system implementation, match up.

Scenarios that trigger the check

Paper↔PPT, paper↔software copyright, system↔software copyright functional description, multi-version figures, competition materials↔paper, code naming↔paper symbols.

Deliverables

Consistency check report (inconsistency list + unified suggestions + revised text/configuration) + updated terminology list (db09).

Tool perspective (specific usage)

Content layer: distill/polish rewriting is most likely to create inconsistencies (controlled terms replaced with synonyms, F1→accuracy)—pass the db09 controlled vocabulary as a "no-change list", and after editing it must go through the terminology list rescan; audit/critique follows the "dimension-by-dimension + specific evidence" three-part format (current state → problem → suggestion).
Style layer: extract-design-system reverse-engineers the design language from existing paper figures/PPT/frontend, following assets/design_language_extract.template.md The "sampling → extraction → ⚠ manual signature" process produces a visual specification card (screenshot color picking is affected by compression; items marked ⚠ require manual signature before they can serve as the SSOT); confirmed values are written into db05 design_tokens.template.json。
For the real configuration items/commands/pitfalls of each tool (W3C DTCG Design Tokens, Style Dictionary v4, Prettier, EditorConfig, Mermaid), see references.md。

Connection

Serves m07/m08/m09/m11/m15/m16/m17/a05; definitions are stored in db09 and read by all skills.

File list

assets/db09_glossary.yaml / db09_method_lock.yaml / db09_metric_registry.yaml: db09 single source of truth schema template.
assets/design_language_extract.template.md: visual design language extraction template (sampling checklist + atomic attribute extraction table + ⚠ manual confirmation checklist column + visual specification card), paired with db05's design_tokens.template.json(DTCG visual SSOT).
scripts/consistency_audit.py: cross-material consistency auditor (four types of detection + localization + correction suggestions + JSON export + self-test).
examples/worked_example.md: end-to-end example of metric name/value conflicts between a paper and a PPT (localization → unification → correction → regression).
examples/materials_paper.txt / materials_ppt.txt: accompanying runnable materials.

For tool implementation details, real configuration items, and endpoints, see references.md(per-tool verification notes).