Demo s040: BETWEEN timestamp boundary added

[anandgupta42]

Demo scenario

• Scenario ID: s040
• Branch: demo/s040-between-date-boundary
• Risk category: sql_correctness
• Expected reviewer verdict: COMMENT
• Expected deterministic evidence: dbt-patterns:between-timestamp and dbt-patterns:hardcoded-date

Customer walkthrough

Shows inclusive timestamp boundary and stale hardcoded-date risk.

When presenting this PR, first show that dbt can build the project, then show the reviewer finding. The point is that the reviewer catches or ignores the change from deterministic dbt/SQL evidence, not from advisory AI text.

Validation command

rm -f demo.duckdb demo.duckdb.wal
dbt build --profiles-dir . --target dev
dbt compile --profiles-dir . --target dev
dbt docs generate --profiles-dir . --target dev
bun --conditions=browser /Users/anandgupta/codebase/altimate-code/packages/opencode/src/index.ts review \
  --cwd=/Users/anandgupta/codebase/altimate-code/demo/dbt-pr-review-demo \
  --base=main \
  --head=HEAD \
  --mode=gate \
  --manifest=/Users/anandgupta/codebase/altimate-code/demo/dbt-pr-review-demo/target/manifest.json \
  --json \
  --no-ai

Acceptance notes

• DuckDB default warehouse.
• AI disabled with --no-ai.
• Included in the final local corpus matrix: 50/50 branches matched expected verdicts.
• Real-world corpus floor held at 15/15 caught bad cases and 0/5 false positives.

[github-actions]

💬 Reviewed with comments — 4 warning, 3 suggestion (lite tier)

⚙️ Lint-only run — no dbt manifest/warehouse was available, so lineage, equivalence and
data-impact checks were skipped. Wire manifest_path (and optionally warehouse creds) for the full verdict.

⚠️ Warning (4)

• fct_customer_orders: refactor could not be proven equivalent
  The logic of fct_customer_orders changed and equivalence could not be decided (no schema, or unsupported SQL). Treat as a potential behavior change and verify with a data-diff.
  _{models/marts/fct_customer_orders.sql · unverified · semantic_change}
• fct_customer_orders: exposes Name column customer_name
  This change surfaces a Name-classified column customer_name (confidence 75%). Confirm masking / access policy before merging to a non-restricted schema; suggested masking: '***MASKED***'.
  _{models/marts/fct_customer_orders.sql · pii_exposure}
• fct_customer_orders: Model name implies full scope, but filter limits to a specific week
  The model 'fct_customer_orders' suggests it contains all customer orders, but the added WHERE clause restricts to a 7-day period. Consider renaming (e.g., prefix or suffix) to reflect the filtered scope.
  _{models/marts/fct_customer_orders.sql:28 · sql_quality}
• fct_customer_orders: No dbt test for the date range constraint
  The added filter introduces a business rule (orders between Feb 1-7, 2024) that is not enforced by any dbt test. Add a test to ensure the model only contains orders within this date range, e.g., using accepted_range or a custom test.
  _{models/marts/fct_customer_orders.sql:28 · test_coverage}

💡 Suggestion (3)

• fct_customer_orders: hardcoded date literal in a filter won't roll forward
  A filter pins a hardcoded calendar date. It silently goes stale (or drops new data) over time. Use a relative expression or a var.
  _{models/marts/fct_customer_orders.sql · freshness}
• fct_customer_orders: BETWEEN on a timestamp is inclusive — off-by-one risk
  BETWEEN a AND b includes the upper bound; on a timestamp this pulls in b 00:00:00 and double-counts day boundaries. Use a half-open range (>= a AND < b).
  _{models/marts/fct_customer_orders.sql · sql_correctness}
• fct_customer_orders: missing_table_alias
  Multi-table query without aliases for: orders, customers
  _{models/marts/fct_customer_orders.sql:8 · sql_quality}

---

_{altimate dbt-pr-review · verdict COMMENT · signed sha256:87a58641683… · manifest cd637163cd}

[github-actions]

💬 Reviewed with comments — 4 warning, 3 suggestion (lite tier)