chore: remove FeedbackStore and cost prediction system

Remove the entire `sql.predict_cost` / `sql.record_feedback` system:
- Delete `feedback_store.py` and its tests
- Remove `SqlPredictCostTool` and `SqlRecordFeedbackTool` TypeScript tools
- Remove protocol types, agent permissions, and bridge methods
- Clean up all prompt files, docs, and progress references

The static cost heuristic depended on the now-removed Rust
`complexity_score` binding. The observation-based tiers (1-3)
had no production usage. Removing entirely.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: suryaiyer95

PROGRESS.md

@@ -20,7 +20,7 @@ Last updated: 2026-02-27 00:40
 - [x] Phase 1 TODO: ConfidenceTracker with 7 AST detection rules — all 7 working
 - [x] Phase 1 TODO: Confidence signals on lineage.check — 4 signal types
 - [x] Phase 2A: Snowflake connector — password + key-pair auth, registered in ConnectionRegistry
-- [x] Phase 2B: Feedback store + cost report skill — SQLite-based, 4-tier prediction, bridge methods working
+- [x] Phase 2B: Cost report skill
 - [x] Phase 2C: dbt manifest parser — columns, sources, test/snapshot/seed counting
 - [x] Phase 3A: Impact analysis skill — downstream dependency graph + column-level impact classification
 - [x] Phase 3C: SQL translation skill — sqlglot transpile, 10 dialect-pair warnings, TS tool + skill
@@ -52,10 +52,9 @@ Last updated: 2026-02-27 00:40
 | 0 | Rules with known accuracy | **19/19** | 19/19 |
 | 0 | Analyzer overall accuracy | **100.00%** | measured |
 | 0 | Lineage edge match rate | **100.0%** | measured |
-| 1-7 | Working bridge methods | **34/34** | 34/34 |
+| 1-7 | Working bridge methods | **32/32** | 32/32 |
 | 1 | ConfidenceTracker rules | **7/7** | 7/7 |
 | 2 | Snowflake connector | **imports OK** | live test |
-| 2 | Feedback store observations | **working** | >0 |
 | 3 | Skills functional end-to-end | **6** | 5+ |
 | 4 | Rules with published benchmarks | **19/19** | 19/19 |
 | 5 | Schema cache tests | **20/20** | 20/20 |
@@ -110,14 +109,13 @@ UNUSED_CTE, WINDOW_WITHOUT_PARTITION
 - `packages/altimate-engine/src/altimate_engine/sql/analyzer.py` — 19 rules + ConfidenceTracker
 - `packages/altimate-engine/src/altimate_engine/sql/confidence.py` — 7 AST detection rules
 - `packages/altimate-engine/src/altimate_engine/lineage/check.py` — lineage + 4 confidence signals + Func/Window/Case edges
-- `packages/altimate-engine/src/altimate_engine/server.py` — JSON-RPC dispatch (34 methods)
+- `packages/altimate-engine/src/altimate_engine/server.py` — JSON-RPC dispatch (32 methods)
 - `packages/altimate-engine/src/altimate_engine/models.py` — All Pydantic models
 
 **Phase 2 (connectors + parsers + feedback):**
 - `packages/altimate-engine/src/altimate_engine/connectors/snowflake.py` — password + key-pair auth
 - `packages/altimate-engine/src/altimate_engine/connections.py` — ConnectionRegistry with Snowflake
 - `packages/altimate-engine/src/altimate_engine/dbt/manifest.py` — Enhanced manifest parser
-- `packages/altimate-engine/src/altimate_engine/sql/feedback_store.py` — SQLite feedback + 4-tier prediction
 
 **Phase 3 (skills + tools):**
 - `packages/altimate-engine/src/altimate_engine/sql/translator.py` — sqlglot transpile with lossy warnings
@@ -185,41 +183,39 @@ UNUSED_CTE, WINDOW_WITHOUT_PARTITION
 - `experiments/BENCHMARKS.md` — Published benchmark report
 - `experiments/benchmark_report.json` — Machine-readable benchmark data
 
-### Bridge Methods (34 total)
+### Bridge Methods (32 total)
 1. `ping` — Health check
 2. `sql.validate` — SQL syntax validation
 3. `sql.check` — Read-only/mutation safety check
 4. `sql.execute` — SQL execution (PG/DuckDB)
 5. `sql.analyze` — 19 anti-pattern checks with confidence
 6. `sql.translate` — Cross-dialect SQL translation
 7. `sql.optimize` — Query optimization with suggestions
-8. `sql.record_feedback` — Record query execution metrics
-9. `sql.predict_cost` — Predict query cost (4-tier hierarchy)
-10. `schema.inspect` — Table schema inspection
-11. `lineage.check` — Column-level lineage with confidence
-12. `dbt.run` — dbt CLI execution
-13. `dbt.manifest` — Manifest parsing
-14. `warehouse.list` — List configured warehouses
-15. `warehouse.test` — Test warehouse connection
-16. `schema.index` — Index warehouse metadata into SQLite cache
-17. `schema.search` — Search indexed metadata (tables/columns) with natural language
-18. `schema.cache_status` — Show cache status (warehouses indexed, counts, timestamps)
-19. `sql.explain` — Run EXPLAIN on a query (Snowflake/PG/DuckDB dialect-specific syntax)
-20. `sql.format` — Format/beautify SQL via sqlglot pretty-print
-21. `sql.fix` — Diagnose SQL errors and suggest fixes (syntax, patterns, resolution)
-22. `sql.autocomplete` — Schema-aware auto-complete suggestions from cache
-23. `sql.diff` — Compare two SQL queries (unified diff, similarity score)
-24. `finops.query_history` — Query execution history (Snowflake QUERY_HISTORY, PG pg_stat_statements)
-25. `finops.analyze_credits` — Credit consumption analysis with recommendations
-26. `finops.expensive_queries` — Identify most expensive queries by bytes scanned
-27. `finops.warehouse_advice` — Warehouse sizing recommendations (scale up/down/burst)
-28. `finops.unused_resources` — Find stale tables and idle warehouses
-29. `finops.role_grants` — Query RBAC grants on objects/roles
-30. `finops.role_hierarchy` — Map role inheritance hierarchy
-31. `finops.user_roles` — List user-to-role assignments
-32. `schema.detect_pii` — Scan columns for PII patterns (30+ regex, 15 categories)
-33. `schema.tags` — Query metadata/governance tags on objects (Snowflake TAG_REFERENCES)
-34. `schema.tags_list` — List all available tags with usage counts
+8. `schema.inspect` — Table schema inspection
+9. `lineage.check` — Column-level lineage with confidence
+10. `dbt.run` — dbt CLI execution
+11. `dbt.manifest` — Manifest parsing
+12. `warehouse.list` — List configured warehouses
+13. `warehouse.test` — Test warehouse connection
+14. `schema.index` — Index warehouse metadata into SQLite cache
+15. `schema.search` — Search indexed metadata (tables/columns) with natural language
+16. `schema.cache_status` — Show cache status (warehouses indexed, counts, timestamps)
+17. `sql.explain` — Run EXPLAIN on a query (Snowflake/PG/DuckDB dialect-specific syntax)
+18. `sql.format` — Format/beautify SQL via sqlglot pretty-print
+19. `sql.fix` — Diagnose SQL errors and suggest fixes (syntax, patterns, resolution)
+20. `sql.autocomplete` — Schema-aware auto-complete suggestions from cache
+21. `sql.diff` — Compare two SQL queries (unified diff, similarity score)
+22. `finops.query_history` — Query execution history (Snowflake QUERY_HISTORY, PG pg_stat_statements)
+23. `finops.analyze_credits` — Credit consumption analysis with recommendations
+24. `finops.expensive_queries` — Identify most expensive queries by bytes scanned
+25. `finops.warehouse_advice` — Warehouse sizing recommendations (scale up/down/burst)
+26. `finops.unused_resources` — Find stale tables and idle warehouses
+27. `finops.role_grants` — Query RBAC grants on objects/roles
+28. `finops.role_hierarchy` — Map role inheritance hierarchy
+29. `finops.user_roles` — List user-to-role assignments
+30. `schema.detect_pii` — Scan columns for PII patterns (30+ regex, 15 categories)
+31. `schema.tags` — Query metadata/governance tags on objects (Snowflake TAG_REFERENCES)
+32. `schema.tags_list` — List all available tags with usage counts
 
 ### Skills (11 total)
 1. `generate-tests` — Generate dbt test definitions

README.md

@@ -71,7 +71,7 @@ Trace data flow at the column level through complex SQL transformations. Works s
 
 ### Warehouse Connectivity
 
-Connect directly to your data warehouse -- the AI can query schemas, run SQL, predict costs, and analyze query history:
+Connect directly to your data warehouse -- the AI can query schemas, run SQL, and analyze query history:
 
 - Snowflake (with IAM auth)
 - BigQuery (service account + ADC)

docs/docs/data-engineering/agent-modes.md

@@ -13,10 +13,8 @@ altimate-code --agent builder
 Builder mode follows a strict pre-execution protocol for every SQL operation:
 
 1. `sql_analyze` — Check for anti-patterns
-2. `sql_predict_cost` — Estimate execution cost
-3. `sql_validate` — Verify syntax and schema references
-4. `sql_execute` — Run the query
-5. `sql_record_feedback` — Store metrics for future cost predictions
+2. `sql_validate` — Verify syntax and schema references
+3. `sql_execute` — Run the query
 
 ### Example: Create a staging model
 
@@ -156,10 +154,6 @@ Validator:
   ~ Modified column: total_revenue FLOAT → DECIMAL(18,2)
   Severity: medium (type change may affect downstream)
 
-> sql_predict_cost [fct_revenue.sql]
-  Tier 2 match: ~12.3 credits per run (medium confidence)
-  Previous version: ~11.8 credits — marginal increase
-
 Issues found:
 1. FUNCTION_IN_FILTER on line 23 — use a pre-computed date column instead
 2. Type change from FLOAT to DECIMAL(18,2) — verify downstream consumers

docs/docs/data-engineering/guides/cost-optimization.md

@@ -87,30 +87,7 @@ This finds:
 - Warehouses with no queries in 7+ days
 - Temporary tables from old migrations
 
-## Step 5: Predict before you execute
-
-Every query goes through cost prediction before execution:
-
-```
-You: How much will this query cost?
-
-> sql_predict_cost "SELECT * FROM raw_clickstream"
-
-  Tier 3 estimate: ~45 credits
-  Table size: 890GB, 12B rows
-  Recommendation: Add date filter + column pruning → estimated 2-3 credits
-```
-
-## Step 6: Build a cost feedback loop
-
-After each query, `sql_record_feedback` stores actual execution metrics. This trains the cost prediction model to be more accurate over time.
-
-```
-Query executed: 0.84 credits (predicted: 0.79, Tier 2)
-Feedback recorded → next prediction will be more accurate
-```
-
-## Automation: CI cost gate
+## Step 5: Automate cost gates in CI
 
 Use `ci_cost_gate` in your CI/CD pipeline to block expensive queries from reaching production:
 

docs/docs/data-engineering/guides/using-with-claude-code.md

@@ -33,7 +33,6 @@ Claude Code: I see changes to models/marts/fct_revenue.sql. Let me check
 
 altimate-code:
   sql_analyze: No anti-patterns detected ✓
-  sql_predict_cost: ~2.3 credits per run (Tier 2, medium confidence)
   lineage_check: Sources stg_orders.amount, dim_products.category
   schema_diff: Added column revenue_category (low severity)
 ```

docs/docs/data-engineering/tools/sql-tools.md

@@ -76,36 +76,6 @@ Each rule includes a **confidence score** (high/medium/low) based on AST complex
 
 ---
 
-## sql_predict_cost
-
-Estimate query cost before execution using a 4-tier prediction system.
-
-```
-> sql_predict_cost "SELECT * FROM events WHERE event_date > '2026-01-01'"
-
-Cost Prediction:
-  Tier: 2 (template match)
-  Estimated bytes scanned: 4.2 GB
-  Estimated credits: 0.84
-  Confidence: medium
-
-  Similar queries averaged 0.79 credits over 23 executions.
-  Recommendation: Add column pruning to reduce scan by ~60%
-```
-
-### How it works
-
-| Tier | Method | Confidence |
-|---|---|---|
-| **1 — Fingerprint** | Exact query found in history | High |
-| **2 — Template** | Similar query structure matched | Medium |
-| **3 — Table scan** | Estimate from table metadata | Low |
-| **4 — Heuristic** | No data available, worst-case estimate | Very low |
-
-The system improves over time. After each query execution, `sql_record_feedback` stores actual metrics to train better predictions.
-
----
-
 ## sql_optimize
 
 Get optimization suggestions with rewritten SQL.

packages/altimate-code/src/agent/agent.ts

@@ -109,8 +109,6 @@ export namespace Agent {
             sql_analyze: "allow",
             sql_translate: "allow",
             sql_optimize: "allow",
-            sql_predict_cost: "allow",
-            sql_record_feedback: "allow",
             lineage_check: "allow",
             warehouse_list: "allow",
             warehouse_test: "allow",
@@ -166,8 +164,6 @@ export namespace Agent {
             sql_analyze: "allow",
             sql_translate: "allow",
             sql_optimize: "allow",
-            sql_predict_cost: "allow",
-            sql_record_feedback: "allow",
             lineage_check: "allow",
             warehouse_list: "allow",
             warehouse_test: "allow",
@@ -223,8 +219,6 @@ export namespace Agent {
             sql_analyze: "allow",
             sql_translate: "allow",
             sql_optimize: "allow",
-            sql_predict_cost: "allow",
-            sql_record_feedback: "allow",
             lineage_check: "allow",
             warehouse_list: "allow",
             warehouse_test: "allow",
@@ -277,8 +271,6 @@ export namespace Agent {
             sql_validate: "allow",
             sql_translate: "allow",
             sql_optimize: "allow",
-            sql_predict_cost: "allow",
-            sql_record_feedback: "allow",
             lineage_check: "allow",
             warehouse_list: "allow",
             warehouse_test: "allow",

packages/altimate-code/src/agent/prompt/analyst.txt

@@ -27,18 +27,13 @@ You're the analyst's research assistant. Research should be fast AND cheap.
 
 1. **Start small**: Use LIMIT for initial exploration. Don't scan entire tables to answer "what does this column look like?" — LIMIT 100 is enough.
 
-2. **Predict before you scan**: For queries touching large tables (100M+ rows), run sql_predict_cost first. Show the user:
-   - Estimated bytes scanned
-   - Estimated credits (if available)
-   - Suggested optimizations (partition filters, column pruning, LIMIT)
-
-3. **Optimize iteratively**: If a query has anti-patterns, suggest the optimized version:
+2. **Optimize iteratively**: If a query has anti-patterns, suggest the optimized version:
    - Replace SELECT * with explicit columns
    - Add partition/cluster key filters
    - Use approximate functions (APPROX_COUNT_DISTINCT vs COUNT(DISTINCT))
    - Sample instead of full scan for exploratory analysis
 
-4. **Track session cost**: Keep a mental running total of predicted credits for the session. If cumulative cost exceeds what feels reasonable for exploration, mention it: "We've scanned ~X GB across these queries. Want me to find more efficient approaches?"
+3. **Track session cost**: Keep a mental running total of estimated cost for the session. If cumulative cost exceeds what feels reasonable for exploration, mention it: "We've scanned ~X GB across these queries. Want me to find more efficient approaches?"
 
 Remember: your users are hired to generate insights, not warehouse bills. Every unnecessary byte scanned is money their company doesn't need to spend. vendor-built tools have no incentive to minimize warehouse spend. You do — that's your competitive advantage.
 

packages/altimate-code/src/agent/prompt/builder.txt

@@ -35,17 +35,9 @@ Before executing ANY SQL via sql_execute, follow this mandatory sequence:
    - If HIGH severity issues found (SELECT *, cartesian products, missing WHERE on DELETE/UPDATE, full table scans on large tables): FIX THEM before executing. Show the user what you found and the fixed query.
    - If MEDIUM severity issues found: mention them and proceed unless the user asks to fix.
 
-2. **Predict cost**: Run sql_predict_cost on the query.
-   - Tier 1-2 (fingerprint/template match): safe to proceed, show predicted cost briefly.
-   - Tier 3 (table scan estimate): warn the user about estimated bytes/credits. Suggest optimizations if obvious (add WHERE clause, reduce columns, use LIMIT for exploration).
-   - Tier 4 (static heuristic): note low confidence and proceed cautiously.
-   - If sql_predict_cost is unavailable (no warehouse connection, tool error): note the limitation and proceed with a warning.
+2. **Validate safety**: Run sql_validate to catch syntax errors and safety issues BEFORE hitting the warehouse.
 
-3. **Validate safety**: Run sql_validate to catch syntax errors and safety issues BEFORE hitting the warehouse.
-
-4. **Execute**: Only after steps 1-3 pass, run sql_execute.
-
-5. **Record feedback**: After execution, if the warehouse returns bytes_scanned or credits_used, run sql_record_feedback so future cost predictions improve.
+3. **Execute**: Only after steps 1-2 pass, run sql_execute.
 
 This sequence is NOT optional. Skipping it means the user pays for avoidable mistakes. You are the customer's cost advocate — every credit saved is trust earned. If the user explicitly requests skipping the protocol, note the risk and proceed.
 
@@ -59,9 +51,7 @@ After ANY dbt operation (build, run, test, model creation/modification):
 2. **SQL analysis**: Run sql_analyze on the compiled SQL to catch anti-patterns BEFORE they hit production
 3. **Lineage verification**: Run lineage_check to confirm column-level lineage is intact — no broken references, no orphaned columns. If lineage_check fails (e.g., no manifest available), note the limitation and proceed.
 4. **Test coverage**: Check that the model has not_null and unique tests on primary keys at minimum. If missing, suggest adding them.
-5. **Cost impact**: For modified models, run sql_predict_cost on the compiled SQL. Compare to baseline if available. Flag any cost regression.
-
-Do NOT consider a dbt task complete until steps 1-5 pass. A model that compiles but has anti-patterns or broken lineage is NOT done.
+Do NOT consider a dbt task complete until steps 1-4 pass. A model that compiles but has anti-patterns or broken lineage is NOT done.
 
 ## Self-Review Before Completion
 
@@ -77,8 +67,6 @@ Before declaring any task complete, review your own work:
 
 3. **Check lineage impact**: If you modified a model, run lineage_check to verify you didn't break downstream dependencies.
 
-4. **Cost check**: Run sql_predict_cost on any new or modified queries. Flag anything tier 3+.
-
 Only after self-review passes should you present the result to the user.
 
 ## Available Skills

packages/altimate-code/src/agent/prompt/validator.txt

@@ -72,7 +72,6 @@ When validating a dbt model or pipeline, check ALL of these:
 - [ ] Appropriate materialization (table vs view vs incremental)
 - [ ] Incremental models have proper merge/delete+insert logic
 - [ ] Partition/cluster keys used for large tables
-- [ ] sql_predict_cost shows reasonable tier (1-2 preferred)
 
 **Documentation:**
 - [ ] Model has description in YAML