universal-dev-standards 5.17.0 → 6.1.0

package/bundled/core/container-image-standards.md

@@ -0,0 +1,97 @@
+# Container Image Build and Security Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/container-image-standards.ai.yaml`
+> **Spec**: XSPEC-065 (cross-project/specs/XSPEC-065-uds-infrastructure-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines security and compliance requirements for container image
+build pipelines. It covers five Dockerfile authoring principles (multi-stage
+builds, non-root execution, minimal base images, secret-free build args, SBOM
+metadata), SBOM generation and embedding using `syft` or `trivy`, and image
+scanning policies that block Critical/High CVEs.
+
+It is part of the **IaC pack** (XSPEC-065) and complements the existing
+`containerization-standards` (layer ordering and tagging) by focusing on
+supply-chain security and compliance attestation.
+
+> **Scope.** This standard defines *what* a production image must guarantee
+> (rootless, minimal, scanned, SBOM-attested) and the *severity policy* for CVEs.
+> The concrete SBOM tool (`syft`/`trivy`), scanner, and registry are adoption
+> choices, not part of this standard.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Dockerfile five principles (multi-stage, non-root, minimal base, no secrets, SBOM label) | MUST |
+| REQ-002 | SBOM embedding (generated in CI, embedded or attested, retained ≥12 months) | MUST |
+| REQ-003 | Image scanning (Critical/High block; Medium ticketed; auto base updates) | MUST |
+
+### REQ-001 — Dockerfile Five Principles
+
+Every production Dockerfile MUST follow five principles: (1) **Multi-stage build**
+— separate builder and runtime stages to minimize final image size and attack
+surface; (2) **Non-root final user** — the runtime stage MUST set a non-root
+`USER` (UID ≥ 1000); running as root in production containers is prohibited;
+(3) **Distroless or Alpine base** — use distroless (`gcr.io/distroless`) or
+Alpine-based images as the final stage to minimize CVE exposure; avoid full
+Debian/Ubuntu unless justified and documented; (4) **No hardcoded secrets** —
+build ARGs and ENV variables MUST NOT contain secrets; secrets are injected at
+runtime via volume mounts or secret managers (see `secret-management-standards`);
+(5) **SBOM metadata label** — the final image MUST include an OCI label
+`org.opencontainers.image.source` and a build-time label
+`org.opencontainers.image.revision` containing the git commit SHA.
+
+### REQ-002 — SBOM Embedding
+
+Every production container image MUST have a Software Bill of Materials (SBOM)
+generated during the CI build step, using `syft` or `trivy` in CycloneDX or SPDX
+format. The SBOM MUST be either (a) embedded as an OCI image annotation
+(preferred for OCI-compliant registries), or (b) attached as a `cosign`
+attestation to the image digest. SBOM artifacts MUST be stored alongside the
+image in the container registry and retained for at least 12 months for
+compliance audits.
+
+### REQ-003 — Image Scanning
+
+All container images MUST be scanned for known CVEs before being pushed to a
+production registry, using `trivy`, `grype`, or equivalent integrated into the CI
+pipeline. Severity policy: **Critical and High** CVEs MUST block the build and
+prevent promotion to production; **Medium** CVEs MUST generate a warning and
+create a tracked ticket; **Low and Negligible** CVEs are informational only.
+Base image updates MUST be triggered automatically when upstream images receive
+CVE patches (e.g., via Dependabot or Renovate for Dockerfile base image pins).
+
+## Anti-Patterns
+
+- Using the `latest` tag for base images in production Dockerfiles (non-reproducible builds).
+- Running container processes as root (UID 0) in the final runtime stage.
+- Embedding secrets in Docker build ARGs or ENV variables that persist in image layers.
+- Skipping SBOM generation to save CI time, losing supply-chain traceability.
+- Pushing images to production without CVE scanning results.
+
+## Integration with Existing Standards
+
+- **`containerization-standards`** — covers layer ordering and tagging; this
+  standard adds the supply-chain-security and attestation layer on top.
+- **`secret-management-standards`** — runtime secret injection replaces any
+  build-time secret in ARGs/ENV (REQ-001 principle 4).
+- **`supply-chain-security-standards`** — the SBOM and CVE-scanning policy here is
+  the container-image facet of the broader supply-chain posture.
+- **`iac-design-principles`** — image build/promotion is itself versioned,
+  reproducible infrastructure.
+
+## Related Specs
+
+- XSPEC-065 — UDS infrastructure (IaC) pack (this standard's source)
+- DEC-043 — UDS coverage completeness roadmap (Wave 4 scope)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~003: Dockerfile five principles, SBOM embedding, image scanning (XSPEC-065) |

package/bundled/core/context-aware-loading.md

@@ -46,7 +46,7 @@ These standards are fundamental to every AI interaction and must always be loade
 |--------|-----------|---------------------|
 | `testing` | testing, unit-testing, integration-testing, test-completeness-dimensions, tdd, bdd, atdd | Writing tests, test file edits, "test coverage" discussion |
 | `specification` | spec-driven-development, forward-derivation, reverse-engineering, requirement-engineering | `/sdd`, `/spec` commands, spec file edits |
-| `quality` | code-review, refactoring, security, performance, accessibility | `/review` command, PR review, "refactor" discussion |
+| `quality` | code-review, refactoring, security, performance, accessibility | `/code-review` command, PR review, "refactor" discussion |
 | `documentation` | documentation-structure, documentation-writing, ai-instruction, changelog | Writing docs, README/CHANGELOG edits |
 | `workflow` | git-workflow, github-flow, squash-merge, versioning, deployment | Branch operations, release preparation, merging |
 | `architecture` | ai-friendly-architecture, project-structure, error-codes, logging | Architecture decisions, project setup |
@@ -62,7 +62,7 @@ Session Start
   ├─ Load all always-on standards
   ├─ Scan user request for trigger keywords
   ├─ Match file patterns if user is editing files
-  ├─ Detect slash commands (/sdd, /review, etc.)
+  ├─ Detect slash commands (/sdd, /code-review, etc.)
   └─ Load matching on-demand standards
 ```
 

package/bundled/core/cost-budget-test.md

@@ -65,7 +65,7 @@ describe("PipelineBudgetConfig semantics", () => {
 ## Related Standards
 
 - [Mutation Testing Standards](mutation-testing.md) — constants without test coverage survive mutations
-- [Testing Standards](testing.md) — overall test pyramid
+- [Testing Standards](testing-standards.md) — overall test pyramid
 - [LLM Output Validation](llm-output-validation.md) — output-layer budget constraints
 
 

package/bundled/core/cross-flow-regression.md

@@ -2,10 +2,11 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/cross-flow-regression.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-05
+**Version**: 1.0.1
+**Last Updated**: 2026-06-18
 **Applicability**: All software projects with multiple user flows or business processes
 **Scope**: universal
+**Owning Spec**: XSPEC-294 (complements flow-based-testing; non-overlapping)
 **Industry Standards**: ISTQB Advanced Test Analyst (Regression Test Strategy)
 **References**: `core/flow-based-testing.md`, `core/testing-standards.md`
 

package/bundled/core/data-contract.md

@@ -0,0 +1,104 @@
+# Data Contract Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/data-contract.ai.yaml`
+> **Spec**: XSPEC-068 (cross-project/specs/XSPEC-068-uds-data-engineering-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines how **data contracts** are established, versioned, and
+enforced between data producers and consumers. A data contract is a formal
+agreement specifying the schema, quality guarantees, SLAs, and ownership of a
+dataset or stream. It covers the contract specification format, freshness and
+quality SLOs, breaking-change governance, consumer registration/notification, and
+automated contract testing. It reduces pipeline failures caused by undiscovered
+upstream changes.
+
+It is part of the **data-engineering pack** (XSPEC-068) and is the **anchor
+standard** for the existing `contract-test-assistant` skill (data-side contracts).
+
+> **Scope.** This standard defines the *contract artifact* (format, SLOs,
+> governance, registration). The concrete data-quality engine (Great
+> Expectations) and catalog (DataHub/Amundsen) are adoption choices.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Data-contract specification format | MUST |
+| REQ-002 | Data-quality SLOs | MUST |
+| REQ-003 | Contract versioning and breaking-change governance | MUST |
+| REQ-004 | Automated contract testing | MUST |
+| REQ-005 | Consumer registration and notification | MUST |
+| REQ-006 | Contract discoverability | SHOULD |
+
+### REQ-001 — Data Contract Specification Format
+
+Every shared dataset or stream MUST have a data contract in a machine-readable
+YAML file (`data-contract.yaml`) committed alongside the producer code. The
+contract MUST include: `contract_id`, `version`, `owner` (team + contact),
+description, `schema` (field names, types, nullability), `data_quality` SLOs
+(completeness, freshness, uniqueness), `sla` (delivery time), and the consumer
+list.
+
+### REQ-002 — Data Quality SLOs
+
+Every contract MUST define explicit data-quality SLOs across these dimensions:
+**completeness** (% non-null for required fields ≥ threshold), **freshness** (data
+updated within N minutes/hours of source), **uniqueness** (% distinct for key
+fields), and **validity** (% conforming to defined format/range). Quality SLO
+violations MUST trigger alerts to both producer and registered consumers.
+
+### REQ-003 — Contract Versioning and Breaking-Change Governance
+
+Contracts MUST use semantic versioning. **PATCH** (backward-compatible additions,
+docs) requires only producer approval. **MINOR** (new optional fields, relaxed
+constraints) requires consumer notification with 7-day notice. **MAJOR** (field
+removal, type/semantic changes) requires consumer approval and MUST NOT deploy
+until all registered consumers confirm readiness.
+
+### REQ-004 — Automated Contract Testing
+
+Contract compliance MUST be verified automatically. Producers MUST run contract
+tests on every pipeline execution, validating output against the declared schema
+and quality SLOs: schema conformance (no unexpected nulls, correct types),
+freshness within the SLO window, uniqueness of key fields, and row count within
+range. Contract test failures MUST halt the pipeline and page the data owner.
+
+### REQ-005 — Consumer Registration and Notification
+
+Teams consuming a shared dataset MUST register as consumers in the producer's
+`data-contract.yaml`, including team name, contact, use-case description, and
+fields consumed. Registered consumers MUST receive automated notifications when:
+the contract is modified, quality SLOs are breached, the dataset is deprecated, or
+planned maintenance affects availability.
+
+### REQ-006 — Contract Discoverability
+
+All data contracts SHOULD be discoverable through a central data catalog providing:
+a searchable index by team/domain, current health status (SLO compliance), schema
+browsing, lineage visualization (which pipelines produce/consume each dataset), and
+a self-service consumer-registration workflow.
+
+## Integration with Existing Standards
+
+- **`contract-test-assistant` (skill)** — this standard is its data-side anchor;
+  the skill's data-contract guidance references these requirements.
+- **`data-pipeline`** — pipelines run contract tests (REQ-004) on every execution.
+- **`schema-evolution`** — MAJOR contract versions correspond to breaking schema
+  changes governed by expand-contract.
+- **`audit-trail` / `pii-classification`** — contract retention and field-level
+  sensitivity align with the compliance pack (XSPEC-066).
+
+## Related Specs
+
+- XSPEC-068 — UDS data-engineering pack (this standard's source)
+- XSPEC-066 — Compliance & audit pack (retention, PII tiering)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: spec format, quality SLOs, versioning/governance, automated testing, consumer registration, discoverability (XSPEC-068) |

package/bundled/core/data-migration-testing.md

@@ -13,6 +13,8 @@ Database schema migrations are high-risk operations: they transform persistent d
 | REQ-DMT-003 | Applying the same migration twice must not fail | CI retries can trigger double-apply |
 | REQ-DMT-004 | Migrations that alter data must include a data preservation test | Schema correctness ≠ data correctness |
 | REQ-DMT-005 | Each test must use an isolated database | Shared state causes non-deterministic failures |
+| REQ-DMT-006 | Migrations that cross encodings or DB engines must include a byte-level encoding conversion test | "Looks equal" hides codepoint/normalization/collation corruption |
+| REQ-DMT-007 | Migrations of business-critical data must include an aggregate invariant test | Row-by-row sampling misses distribution-level drift |
 
 ## Test Structure
 
@@ -78,6 +80,91 @@ it('preserves existing user rows', async () => {
 })
 ```
 
+### Encoding Conversion Test
+
+Schema-level and row-level tests both pass when a string "looks equal" on screen — yet the underlying bytes can be silently corrupted by a cross-encoding or cross-engine move (UTF-8 → UTF-16/`NVARCHAR`, `VARCHAR` → `NVARCHAR`, an implicit collation change). A migration that crosses encodings or DB engines MUST assert equality at the **byte / codepoint / normalization** level, not the display level.
+
+What to assert:
+
+- **Byte / codepoint identity** — the migrated value has the same Unicode codepoints (and, where the target stores UTF-16, the expected unit count), not just the same rendered glyphs.
+- **Normalization form** — NFC vs NFD: `"é"` (U+00E9) and `"e"+◌́` (U+0065 U+0301) render identically but are different byte sequences; assert the form is preserved (or deliberately normalized).
+- **Multi-byte boundaries** — values truncated to a *character* limit on the source must not be truncated to a *byte* limit on the target (a 4-byte emoji must survive a `NVARCHAR(n)` column).
+- **CJK / emoji / combining marks** — exercise supplementary-plane codepoints (emoji, rare CJK) and combining sequences explicitly; these are where surrogate-pair and collation-folding bugs hide.
+
+```typescript
+it('preserves bytes across UTF-8 -> target encoding (no display-only equality)', async () => {
+  // Mix BMP CJK, a supplementary-plane emoji, and an NFD combining sequence
+  const samples = [
+    '繁體中文',           // CJK (BMP)
+    '😀 family 👨‍👩‍👧',     // emoji incl. ZWJ sequence (supplementary plane)
+    'é'             // NFD: 'e' + combining acute (renders like 'é')
+  ]
+  samples.forEach((s, i) =>
+    db.prepare('INSERT INTO notes (id, body) VALUES (?, ?)').run(i, s))
+
+  await migrate.up(db)
+
+  samples.forEach((expected, i) => {
+    const row = db.prepare('SELECT body FROM notes WHERE id = ?').get(i) as { body: string }
+    // ❌ Anti-pattern: expect(row.body).toBe(expected)  // passes even on partial corruption if both render the same
+    // ✅ Assert at the byte and codepoint level:
+    expect(Buffer.from(row.body, 'utf8')).toEqual(Buffer.from(expected, 'utf8'))
+    expect([...row.body]).toEqual([...expected])                 // codepoint-by-codepoint
+    expect(row.body.normalize('NFC')).toBe(expected.normalize('NFC')) // explicit normalization intent
+  })
+})
+```
+
+> **Anti-pattern**: asserting only `expect(actual).toBe(expected)` on the decoded string. Two different byte/normalization sequences can decode to glyphs that *look* identical, so a display-level assertion passes while the stored bytes (and any downstream `LIKE`/unique-key/collation behavior) are corrupted.
+
+### Aggregate Invariant Test
+
+Row sampling proves individual rows survived; it does **not** prove the *distribution* survived. Seed a representative dataset, capture aggregate invariants over business-critical columns **before** the migration, and assert they are unchanged **after**. This is the same oracle used for post-cutover production reconciliation (aggregate equality across the cutover boundary), run here at migration-test time.
+
+Invariants to capture: `COUNT(*)`, `SUM(money_column)`, `COUNT(DISTINCT key)`, and a content `checksum` (e.g. summed hash) grouped by a business dimension such as status or period.
+
+```typescript
+it('preserves aggregate invariants over financial data', async () => {
+  seedRepresentativeOrders(db) // statuses, amounts, currencies
+
+  const invariantQuery = `
+    SELECT status,
+           COUNT(*)            AS cnt,
+           SUM(amount_cents)   AS total_cents,
+           COUNT(DISTINCT customer_id) AS distinct_customers
+    FROM orders
+    GROUP BY status
+    ORDER BY status`
+  const before = db.prepare(invariantQuery).all()
+
+  await migrate.up(db)
+
+  const after = db.prepare(invariantQuery).all()
+  // Distribution must be identical — not just "some rows still exist"
+  expect(after).toEqual(before)
+})
+```
+
+> Because aggregates collapse the whole table into a few numbers, a single mismatched `SUM`/`COUNT` flags drift that row-by-row sampling — which only inspects the rows you happened to pick — would miss entirely.
+
+## Cross-Dialect Migration: SQLite → SQL Server Risk Table
+
+When a migration also changes the database engine (not just the schema), the source and target dialects disagree on type semantics, comparison, and ordering. Each disagreement below is a place where data can silently change meaning, and is a derive-list input for the encoding and aggregate tests above (and for the non-HTTP implicit-rule scan in reverse-engineering-standards.md).
+
+| Risk point | SQLite | SQL Server | What the migration must verify |
+|---|---|---|---|
+| **Type system** | Dynamic typing (per-value type affinity) | Static / strong typing | Declare a type per column; scan for out-of-range / mixed-type values that SQLite tolerated |
+| **Boolean** | Usually stored as `0/1` integer | `BIT` | `0/1` ↔ `BIT` mapping; handling of NULL booleans |
+| **Date / time** | Often stored as `TEXT` / `REAL` / `INTEGER` | `datetime2` / `datetimeoffset` | Format parse, time-zone handling, precision truncation |
+| **Auto-increment PK** | `AUTOINCREMENT` | `IDENTITY` | Continuity of existing ids; correct seed/reseed value |
+| **Case / collation** | `LIKE` case-insensitive by default; `NOCASE` | Determined by column collation | Align collation; check for unique-key folding collisions |
+| **NULL ordering** | NULLs sort first (smallest) | Depends on configuration | `ORDER BY` result-order invariant across engines |
+| **Float precision** | `REAL` | `float` / `decimal` | Move money/exact values to `decimal` to avoid rounding error |
+| **String concat** | `\|\|` | `+` / `CONCAT` | Rewrite queries; reconcile NULL-concatenation semantics |
+| **Pagination** | `LIMIT` / `OFFSET` | `OFFSET .. FETCH` / `TOP` | Rewrite + guarantee a stable sort key for deterministic pages |
+
+> Each "query rewrite / semantics differs" cell may also hide an **implicit business rule** — feed this table into the Implicit Rule Scan stage of reverse engineering.
+
 ## Tooling
 
 ### SQLite / Drizzle ORM
@@ -102,12 +189,15 @@ Use `testcontainers` to spin up a fresh PostgreSQL container per test suite. The
 - **Skipping down migration tests** — rollbacks fail during production incidents
 - **Writing migration tests after the fact without seeding data** — misses data preservation bugs entirely
 - **Committing a migration without a corresponding test** — the migration is untested until production
+- **Asserting string equality only on the decoded value** — display-level equality passes even when bytes, normalization form, or codepoints were corrupted across an encoding/engine change
+- **Validating a cross-engine migration with row sampling alone** — distribution-level drift (a wrong `SUM`/`COUNT`/`DISTINCT`) escapes any sample that happens to miss the affected rows
 
 ## See Also
 
 - `database-standards.ai.yaml` — schema design principles
 - `testing.ai.yaml` — general test structure and pyramid
 - `verification-evidence.ai.yaml` — audit evidence requirements
+- `behavior-snapshot.ai.yaml` — same "don't compare what merely *looks* equal" principle, applied at the oracle/serialization layer rather than the DB storage layer
 
 
 **Scope**: universal

package/bundled/core/data-pipeline.md

@@ -0,0 +1,113 @@
+# Data Pipeline Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/data-pipeline.ai.yaml`
+> **Spec**: XSPEC-068 (cross-project/specs/XSPEC-068-uds-data-engineering-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines engineering requirements for building **reliable,
+observable, and maintainable data pipelines**. It covers idempotency and
+exactly-once semantics, error handling and dead-letter queues, checkpoint and
+recovery, data-lineage tracking, pipeline observability and SLOs, and testing
+requirements. It applies to batch ETL, streaming pipelines, and ML feature
+pipelines.
+
+It is part of the **data-engineering pack** (XSPEC-068). It extends
+`database-standards` (which covers static DB schema) into the movement and
+transformation of data, and reuses the reliability and observability primitives
+of the SRE family (`observability-standards`, `slo-sli`).
+
+> **Scope.** This standard defines the *pipeline design principles* (idempotency,
+> error handling, recovery, lineage, observability, testing). The concrete
+> orchestrator (Airflow/Dagster), lineage store (Marquez/DataHub), and DLQ
+> transport are adoption choices.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Idempotency and exactly-once processing | MUST |
+| REQ-002 | Error handling and dead-letter queues | MUST |
+| REQ-003 | Checkpoint and recovery | MUST |
+| REQ-004 | Data-lineage tracking | MUST |
+| REQ-005 | Pipeline observability and SLOs | MUST |
+| REQ-006 | Pipeline testing requirements | MUST |
+
+### REQ-001 — Idempotency and Exactly-Once Processing
+
+Every pipeline MUST be designed for **idempotent** execution: re-running the same
+pipeline for the same time window or batch MUST produce identical output without
+duplication or data loss. Pipelines MUST use deterministic keys for
+deduplication. Batch pipelines MUST support clean re-processing of historical
+partitions. Streaming pipelines MUST implement exactly-once, or at-least-once with
+deduplication using unique event IDs. For batch jobs, overwriting output
+partitions is preferred over appending.
+
+### REQ-002 — Error Handling and Dead-Letter Queues
+
+Pipelines MUST implement structured error handling with categorized failure modes.
+**Transient** errors (network timeout, API rate limit) MUST use exponential
+backoff retry (max 3 attempts). **Permanent** errors (schema violation, invalid
+data) MUST route records to a Dead-Letter Queue (DLQ) carrying the original
+record, error type, error message, and processing timestamp. DLQ records MUST be
+monitored and addressed within the pipeline's SLA.
+
+### REQ-003 — Checkpoint and Recovery
+
+Long-running batch pipelines and stateful streaming pipelines MUST implement
+**checkpointing** to recover from mid-run failures without full reprocessing.
+Checkpoints MUST record the last successfully processed partition/offset/watermark,
+the job run ID, and a timestamp. Recovery MUST resume from the last checkpoint,
+not from the beginning. Checkpoint state MUST be stored in durable external
+storage, not local disk.
+
+### REQ-004 — Data Lineage Tracking
+
+Every pipeline MUST emit **lineage metadata** describing its data flow: source
+datasets (with versions/timestamps), transformation logic applied, and output
+datasets produced. Lineage MUST be machine-readable and ingested into a central
+lineage store or data catalog, enabling root-cause analysis of data-quality
+issues and impact assessment of upstream changes.
+
+### REQ-005 — Pipeline Observability and SLOs
+
+Every production pipeline MUST expose: records processed (counter), processing
+latency (histogram), error rate (gauge), DLQ depth (gauge), and last successful
+run timestamp. Pipelines MUST define SLOs for **freshness** (data available within
+N hours of source), **completeness** (≥ X% records successfully processed), and
+**latency** (p95 within threshold). SLO violations MUST trigger alerts.
+
+### REQ-006 — Pipeline Testing Requirements
+
+Pipelines MUST have automated tests covering: unit tests for transformation logic
+(sample input/output), integration tests validating end-to-end flow with synthetic
+data, and schema-conformance tests validating output against the declared data
+contract (`data-contract`). Pipelines SHOULD have regression tests for
+historically problematic edge cases (nulls in key fields, negative amounts,
+duplicate records). Test coverage MUST be ≥ 80% for transformation logic.
+
+## Integration with Existing Standards
+
+- **`data-contract`** — schema-conformance tests validate pipeline output against
+  the producer's declared contract and quality SLOs.
+- **`schema-evolution`** — pipelines must tolerate backward-compatible schema
+  changes in their sources.
+- **`observability-standards` / `slo-sli`** — pipeline metrics and freshness/
+  completeness SLOs reuse the SRE observability and SLO primitives.
+- **`database-standards`** — extends the static-schema standard into data movement.
+- **`audit-trail`** — backfills and reprocessing record an audit event (reason).
+
+## Related Specs
+
+- XSPEC-068 — UDS data-engineering pack (this standard's source)
+- XSPEC-066 — Compliance & audit pack (`audit-trail` for backfill reasons)
+- XSPEC-063 — SRE pack (`observability-standards`, `slo-sli`)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: idempotency, error handling/DLQ, checkpoint/recovery, lineage, observability/SLO, testing (XSPEC-068) |

package/bundled/core/deprecation-standards.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/deprecation-standards.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-03-31
+**Version**: 1.1.0
+**Last Updated**: 2026-06-24
 **Applicability**: All software projects
 **Scope**: universal
 **Industry Standards**: RFC 8594 (Sunset Header), RFC 8288 (Web Linking)
@@ -57,6 +57,19 @@ When a new version is released, the old version MUST be maintained for at least
 
 This ensures consumers have adequate time to migrate without service disruption.
 
+### Minimum Deprecation Period by API Tier
+
+The 6-stage Sunset Timeline above shows the **default cadence for a public API** (roughly 6 months of notice from Announce to Sunset). The *minimum* deprecation period scales with the API's audience and criticality. Apply the **longer** of the tier minimum below and the Version Parallel Period above:
+
+| API Tier | Minimum Deprecation Period |
+|----------|----------------------------|
+| **Internal API** | 1 minor version |
+| **Partner API** | 2 minor versions + 3 months |
+| **Public API** | 2 minor versions + 6 months |
+| **Critical Infrastructure** | 1 year minimum |
+
+These are minimums; a longer period may be required by an SLA or contractual commitment (see [Feature Sunset → Impact Analysis](#impact-analysis)). What *counts* as a breaking change that triggers deprecation, and the API versioning mechanics themselves, live in [API Design Standards](api-design-standards.md#api-versioning-strategies) — this standard is the single source of truth only for the deprecation timeline and these notice periods.
+
 ---
 
 ## Consumer Notification Strategy
@@ -200,6 +213,7 @@ No alternative exists?      → Build alternative first
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 1.1.0 | 2026-06-24 | Added: Minimum Deprecation Period by API Tier — establishes this standard as the single source of truth for deprecation periods, consolidated from versioning.md and harmonized with the Sunset Timeline and Version Parallel Period (XSPEC-298 R8, UDS #126) |
 | 1.0.0 | 2026-03-31 | Initial release: API Deprecation, Feature Sunset, System Decommission, Retirement Metrics |
 
 ---

package/bundled/core/developer-memory.md

@@ -2,10 +2,11 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/developer-memory.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-02-07
+**Version**: 1.1.1
+**Last Updated**: 2026-06-18
 **Applicability**: All software projects using AI assistants
 **Scope**: universal
+**Owning Spec**: XSPEC-291 (developer-memory has no dedicated feature XSPEC; XSPEC-291 owns it)
 **Industry Standards**: None (UDS original)
 
 ---
@@ -233,11 +234,14 @@ AI scans the memory store and generates a review report covering:
 
 #### Retirement Suggestions
 
-| Trigger | Action |
-|---------|--------|
-| `confidence < 0.2` | Suggest retirement |
-| Not surfaced in 180+ days AND `confidence < 0.5` | Suggest retirement |
-| 5+ `invalid` feedback entries | Suggest retirement |
+Thresholds are UDS defaults (configurable per project); the rationale is
+recorded so each value is auditable rather than arbitrary.
+
+| Trigger | Action | Rationale |
+|---------|--------|-----------|
+| `confidence < 0.2` | Suggest retirement | Repeatedly invalidated knowledge is more noise than signal |
+| Not surfaced in 180+ days AND `confidence < 0.5` | Suggest retirement | Half-year dormancy combined with low confidence means the memory is no longer relevant to active work; the 180-day window matches the staleness/decay model in Staleness Detection below |
+| 5+ `invalid` feedback entries | Suggest retirement | Sustained negative feedback signals the memory is wrong or obsolete |
 
 #### Staleness Detection
 
@@ -548,7 +552,7 @@ Developer Persistent Memory is classified as an **Always-On Protocol**, not a Us
 
 | Pattern | Characteristics | Examples | Skill Required? |
 |---------|----------------|----------|-----------------|
-| **User-Triggered** | User explicitly invokes, multi-step guided workflow | `/commit`, `/review`, `/sdd` | Yes |
+| **User-Triggered** | User explicitly invokes, multi-step guided workflow | `/commit`, `/code-review`, `/sdd` | Yes |
 | **Always-On Protocol** | AI continuously follows rules after loading ai.yaml | Anti-hallucination, Developer Memory | No |
 
 ### Rationale: No CLI / Skill / Slash Command Needed
@@ -587,6 +591,7 @@ If user feedback reveals:
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 1.1.0 | 2026-06-18 | Added: rationale column + configurable note to Retirement Suggestions thresholds (XSPEC-292 T8) |
 | 1.0.0 | 2026-02-07 | Initial standard: schema, 4 operations, proactive protocol, noise control, architecture decision (Always-On Protocol) |
 
 ---

package/bundled/core/documentation-writing-standards.md

@@ -818,7 +818,7 @@ Track translation status in translated document headers:
 ---
 translation_status: current | needs_update | in_progress
 source_version: 1.2.0
-source_hash: abc123
+source_hash: a1b2c3d4e5f6   # first 12 chars of `git hash-object <source>`
 translated_by: human | machine | machine+human-review
 last_synced: 2026-03-17
 ---
@@ -991,7 +991,7 @@ Ensure documentation is accessible to all users, following WCAG 2.1 Level A guid
 | Requirement | Description | Example |
 |-------------|-------------|---------|
 | **Plain language** | Use clear, simple language; target grade 8 reading level | Avoid: "utilize" → Use: "use" |
-| **Alt text for images** | Provide descriptive alt text for all non-decorative images | `![Architecture diagram showing three-tier layout](arch.png)` |
+| **Alt text for images** | Provide descriptive alt text for all non-decorative images | `![Architecture diagram showing three-tier layout](path/to/arch.png)` |
 | **Heading hierarchy** | Use proper heading levels (h1→h2→h3), never skip levels | Don't jump from `#` to `###` |
 | **Link text** | Use descriptive link text, not "click here" | Avoid: [click here] → Use: [installation guide] |
 | **Code blocks** | Use fenced code blocks with language identifiers | ` ```javascript ` not ` ``` ` |

package/bundled/core/error-code-standards.md

@@ -2,10 +2,11 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/error-code-standards.md)
 
-**Version**: 1.2.0
-**Last Updated**: 2026-03-18
+**Version**: 1.2.1
+**Last Updated**: 2026-06-18
 **Applicability**: All software projects
 **Scope**: universal
+**Owning Spec**: XSPEC-291 (no dedicated feature XSPEC; XSPEC-291 owns this standard)
 **Industry Standards**: RFC 7807, RFC 9457
 **References**: [datatracker.ietf.org](https://datatracker.ietf.org/doc/html/rfc7807)
 
@@ -580,7 +581,7 @@ AUTH_VAL_001
 
 **Related Standards:**
 - [Logging Standards](logging-standards.md) - Error logging practices
-- [API Documentation Standards](api-documentation-standards.md) - Error response documentation
+- [API Documentation Standards](api-design-standards.md) - Error response documentation
 
 ---