turbine-data 0.1.0__tar.gz

turbine_data-0.1.0/.claude/hooks/format-after-edit.sh

@@ -0,0 +1,11 @@
+#!/bin/bash
+# Runs ruff format on .py files after Edit/Write tool calls
+
+INPUT=$(cat)
+FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path')
+
+if [[ -n "$FILE_PATH" && "$FILE_PATH" == *.py ]]; then
+  uv run ruff format "$FILE_PATH" 2>/dev/null
+fi
+
+exit 0

turbine_data-0.1.0/.claude/hooks/pre-commit-lint.sh

@@ -0,0 +1,47 @@
+#!/bin/bash
+# Full quality gate before git commit:
+# ruff check --fix, ruff format, ty check, complexipy, tach check
+
+INPUT=$(cat)
+COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')
+
+if echo "$COMMAND" | grep -q "git commit"; then
+  CWD=$(echo "$INPUT" | jq -r '.cwd')
+  cd "$CWD"
+
+  # Lint + format
+  uv run ruff check --fix . 2>&1
+  RUFF_EXIT=$?
+  uv run ruff format . 2>/dev/null
+
+  if [ $RUFF_EXIT -ne 0 ]; then
+    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"ruff check --fix found unfixable lint errors. Fix them before committing."}}'
+    exit 0
+  fi
+
+  # Type check
+  uv run ty check 2>&1
+  TY_EXIT=$?
+  if [ $TY_EXIT -ne 0 ]; then
+    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"ty check found type errors. Fix them before committing."}}'
+    exit 0
+  fi
+
+  # Complexity check
+  uv run complexipy src/ -mx 10 2>&1
+  COMPLEX_EXIT=$?
+  if [ $COMPLEX_EXIT -ne 0 ]; then
+    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"complexipy found functions exceeding complexity threshold. Simplify before committing."}}'
+    exit 0
+  fi
+
+  # Boundary check
+  uv run tach check 2>&1
+  TACH_EXIT=$?
+  if [ $TACH_EXIT -ne 0 ]; then
+    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"tach check found module boundary violations. Fix imports before committing."}}'
+    exit 0
+  fi
+fi
+
+exit 0

turbine_data-0.1.0/.claude/settings.json

@@ -0,0 +1,26 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": ".claude/hooks/pre-commit-lint.sh"
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": ".claude/hooks/format-after-edit.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

turbine_data-0.1.0/.claude/skills/code-simplification/SKILL.md

@@ -0,0 +1,304 @@
+---
+name: code-simplification
+description: Use after implementing features, before claiming a phase is complete, when reviewing AI-generated code, or when code feels overly complex — detects duplication, dead code, over-engineering, and AI-specific bloat patterns
+---
+
+<!-- TOKEN BUDGET: 370 lines / ~1110 tokens -->
+
+# Code Simplification
+
+## Overview
+
+AI-generated code accumulates complexity. Each task is implemented in isolation by a fresh agent that can't see the full picture. After multiple tasks, duplication creeps in, abstractions multiply, and dead code lingers.
+
+**Core principle:** The simplest code that works correctly is the best code. Complexity is a cost, not a feature.
+
+**This skill applies after implementation, not during.** Don't prematurely optimize — but don't ship bloat either.
+
+## When to Use
+
+**Always:**
+- After all tasks in a phase are complete (before shipping)
+- When reviewing code generated by multiple builder agents
+- When a file has been touched by 3+ different tasks
+- When you notice patterns repeating across files
+- Before claiming a phase is production-ready
+
+**The simplifier agent references this skill for systematic cross-task analysis.**
+
+## Duplication Detection
+
+### What to Look For
+
+**Exact duplicates:** Identical code blocks in different files or functions.
+```
+# RED FLAG: Same logic in two places
+def validate_user_email(email):
+    if not email or "@" not in email:
+        raise ValueError("Invalid email")
+
+def validate_contact_email(email):
+    if not email or "@" not in email:
+        raise ValueError("Invalid email")
+```
+
+**Near duplicates:** Same structure, different details.
+```
+# RED FLAG: Parallel structure, only names differ
+def create_user(data):
+    validate(data)
+    user = User(**data)
+    db.add(user)
+    db.commit()
+    return user
+
+def create_project(data):
+    validate(data)
+    project = Project(**data)
+    db.add(project)
+    db.commit()
+    return project
+```
+
+**Parallel hierarchies:** When adding a new type requires changes in multiple places.
+
+**Copy-paste config:** Same configuration blocks repeated in Docker, Terraform, or CI files.
+
+### The Rule of Three
+
+- **2 occurrences:** Note it, but don't extract yet.
+- **3 occurrences:** Extract. The pattern is real.
+- **1 abstraction serving 1 caller:** Inline it. The abstraction has no value.
+
+## Complexity Reduction
+
+### Techniques
+
+**Extract method:** When a function does too many things.
+```
+# BEFORE: One function doing everything
+def process_order(order):
+    # validate (10 lines)
+    # calculate totals (15 lines)
+    # apply discounts (12 lines)
+    # save to database (8 lines)
+    # send notification (6 lines)
+
+# AFTER: Clear responsibilities
+def process_order(order):
+    validate_order(order)
+    totals = calculate_totals(order)
+    totals = apply_discounts(totals, order.customer)
+    save_order(order, totals)
+    notify_order_placed(order)
+```
+
+**Early returns / guard clauses:** Eliminate deep nesting.
+```
+# BEFORE: Nested conditionals
+def get_discount(user):
+    if user:
+        if user.is_premium:
+            if user.years > 5:
+                return 0.20
+            else:
+                return 0.10
+        else:
+            return 0.0
+    else:
+        return 0.0
+
+# AFTER: Guard clauses
+def get_discount(user):
+    if not user or not user.is_premium:
+        return 0.0
+    if user.years > 5:
+        return 0.20
+    return 0.10
+```
+
+**Replace conditionals with polymorphism:** When type-checking drives behavior.
+
+**Simplify boolean expressions:** Collapse nested boolean logic.
+
+### Complexity Thresholds
+
+| Metric | Acceptable | Review | Refactor |
+|--------|-----------|--------|----------|
+| Function length | < 20 lines | 20-40 lines | > 40 lines |
+| Nesting depth | ≤ 2 levels | 3 levels | > 3 levels |
+| Parameters | ≤ 3 | 4-5 | > 5 |
+| Cyclomatic complexity | ≤ 5 | 6-10 | > 10 |
+
+## Dead Code Identification
+
+### What Counts as Dead Code
+
+- **Unused imports** — imported but never referenced
+- **Unused variables** — assigned but never read
+- **Unreachable branches** — conditions that can never be true
+- **Commented-out code** — if it's needed, it's in git history
+- **Unused functions/methods** — defined but never called
+- **Vestigial parameters** — accepted but never used
+- **Feature flags for shipped features** — the flag is always on
+
+## Over-Engineering Indicators
+
+### Premature Abstraction
+
+```
+# OVER-ENGINEERED: Abstract factory for one implementation
+class NotificationFactory:
+    @staticmethod
+    def create(type):
+        if type == "email":
+            return EmailNotifier()
+        raise ValueError(f"Unknown: {type}")
+
+# SIMPLE: Just use the thing directly
+notifier = EmailNotifier()
+```
+
+**Rule:** If there's only one implementation, don't create an abstraction. Add it when the second implementation arrives.
+
+### Unnecessary Indirection
+
+```
+# OVER-ENGINEERED: Service wrapping a service
+class UserService:
+    def get_user(self, id):
+        return self.repository.get_user(id)  # Just passes through
+
+# SIMPLE: Use the repository directly where needed
+user = repository.get_user(id)
+```
+
+### Configuration for One Value
+
+```
+# OVER-ENGINEERED
+MAX_RETRIES = config.get("max_retries", 3)
+
+# SIMPLE (if this is the only place retries happen)
+MAX_RETRIES = 3
+```
+
+**Rule:** Make it configurable when a second consumer needs a different value, not before.
+
+## AI-Specific Anti-Patterns
+
+AI code generators commonly produce these patterns. Watch for them:
+
+### Verbose Error Handling
+```
+# AI BLOAT: Every function has identical error handling
+def get_user(id):
+    try:
+        user = db.query(User).get(id)
+        if user is None:
+            raise ValueError(f"User {id} not found")
+        return user
+    except ValueError:
+        raise
+    except Exception as e:
+        logger.error(f"Error getting user: {e}")
+        raise RuntimeError(f"Failed to get user {id}") from e
+
+# SIMPLER: Let exceptions propagate naturally
+def get_user(id):
+    user = db.query(User).get(id)
+    if user is None:
+        raise ValueError(f"User {id} not found")
+    return user
+```
+
+### Redundant Type Checks
+```
+# AI BLOAT: Checking types that can't be wrong
+def process(items: list[str]) -> None:
+    if not isinstance(items, list):
+        raise TypeError("Expected list")
+    for item in items:
+        if not isinstance(item, str):
+            raise TypeError("Expected str")
+        # actual logic...
+
+# SIMPLER: Trust the type system
+def process(items: list[str]) -> None:
+    for item in items:
+        # actual logic...
+```
+
+### Over-Defensive Coding
+```
+# AI BLOAT: Null checks where nulls can't happen
+user = get_authenticated_user()  # Already validated by middleware
+if user is not None and user.id is not None:  # Impossible to be None
+    process(user)
+
+# SIMPLER: Trust your system boundaries
+user = get_authenticated_user()
+process(user)
+```
+
+### Unnecessary Wrapper Functions
+```
+# AI BLOAT: Wrapping standard library
+def read_json_file(path):
+    with open(path) as f:
+        return json.load(f)
+
+# Used exactly once — just inline it
+with open(config_path) as f:
+    config = json.load(f)
+```
+
+## Simplification Process
+
+When reviewing code for simplification:
+
+1. **Identify scope:** What files changed in this phase? (Use git diff)
+2. **Scan for duplication:** Look for similar patterns across files
+3. **Check complexity:** Flag functions exceeding thresholds
+4. **Find dead code:** Look for unused definitions
+5. **Spot over-engineering:** Look for abstractions with single implementations
+6. **Check AI patterns:** Apply the AI anti-pattern checklist
+7. **Prioritize findings:**
+   - **High:** Clear duplication (3+), dead code, obvious bloat
+   - **Medium:** Complexity reduction, near-duplicates
+   - **Low:** Style consistency, minor simplifications
+
+## Red Flags — STOP and Simplify
+
+- Same logic in 3+ places
+- Function > 40 lines
+- Nesting > 3 levels
+- Abstract class with one concrete implementation
+- Wrapper that just delegates
+- Config for a value used in one place
+- Try/except that re-raises the same exception
+- Type check for a statically typed parameter
+- Null check after a function that can't return null
+- Commented-out code blocks
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "We might need it later" | YAGNI. Add it when you need it. |
+| "It's more extensible" | Extensibility without use cases is waste. |
+| "The abstraction makes it cleaner" | One caller = inline is cleaner. |
+| "Deleting code feels risky" | Git remembers. Dead code is maintenance cost. |
+| "It's just a few extra lines" | Lines compound. 10 files × 5 extra lines = 50 lines of noise. |
+| "The AI generated it, it must be right" | AI optimizes for completeness, not simplicity. |
+| "Refactoring might break things" | Tests exist. If they don't, add them first. |
+
+## Integration
+
+**Referenced by:**
+- **shipyard:simplifier** — Uses this skill as the analysis framework for cross-task simplification
+- **shipyard:reviewer** — Code quality review (Stage 2) checks for complexity
+
+**Pairs with:**
+- **shipyard:shipyard-tdd** — Tests make simplification safe
+- **shipyard:shipyard-verification** — Simplification claims need evidence

turbine_data-0.1.0/.claude/skills/docs-todo-next/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: docs-todo-next
+description: Process the next unchecked item from docs-todo.md at the repo root. Picks one item, verifies what the code actually does (not what the doc claims), drafts the new or updated page in the established voice, dispatches a reviewer to check the draft against code reality, then ticks the box. Use this whenever the user says "do the next docs todo", "next docs item", "update the docs to match reality", "advance docs-todo", or asks you to walk through docs-todo.md one item at a time. Trigger on any phrasing that asks for forward progress on the docs-todo list, even when the user does not name the file.
+---
+
+# docs-todo-next
+
+A loop that turns one line of `docs-todo.md` into a documentation page that matches the code, reviewed and ticked.
+
+## When this skill runs
+
+The user wants to advance the docs todo list one item. The list lives at `docs-todo.md` in the repo root. Every entry is one of three kinds, and the workflow branches accordingly:
+
+- **New page**: write the file and wire it into `docs/user/mkdocs.yml`.
+- **Update**: open the existing page, find what is wrong against the code, rewrite the wrong parts.
+- **Delete**: remove the file, remove its nav entry, remove redirects pointing at it.
+
+## Step-by-step
+
+### 1. Pick the next item
+
+Read `/Users/yassin/Documents/projects/turbine-lsp/docs-todo.md`. Find the first `- [ ]` line, top to bottom. The "Missing sections to add" and "Sections to remove" blocks come before page-by-page review, which matches the user's preferred working order.
+
+If every box is ticked, say so and stop.
+
+Capture the audit hints from the parenthetical (for example `(NEEDS UPDATE: failed_rows/values_in missing from CHECK_CATALOG)`). Treat those hints as **leads to verify**, not as truth. The audit was a snapshot. The code is the source of truth.
+
+### 2. Read the existing doc, if any
+
+For an update or a delete, read the current file end to end. For a new page, skim the neighbouring pages it will sit beside in the nav so the new page lands in the same voice and depth.
+
+### 3. Verify what the code actually does
+
+Do not trust the doc. Do not trust the audit hint. Read the code.
+
+For a typical page, that means:
+
+- Use `grep -rn` on `src/turbine/` for every CLI flag, YAML field, class name, function name, and rule name the doc currently mentions or the new doc will mention.
+- Read the relevant module top to bottom. Skimming misses the things that change between versions.
+- Pay attention to:
+  - Default values (the doc often lags behind the actual default).
+  - Optional vs required (Pydantic models say so; trust the model).
+  - Status enum values (e.g. `retired` vs `removed`, `active` vs `published`).
+  - Lint rule names and severities (look in `core/contract/lint_rules.py`).
+  - DSL field names: camelCase vs snake_case drift is common.
+  - Whether claimed features actually exist. If the doc says "the owner is notified", grep for `notify`/`notification` and confirm. If nothing is wired up, the doc is selling a feature that does not exist; cut the claim.
+
+If the code has moved on but the audit hint still points at the old file, follow imports and call sites to find where the logic lives now.
+
+When in doubt about a feature's true behaviour, dispatch the `code-explorer` subagent with a tight question. Example: "Trace what happens when `turbine ci check` loads a QualitySpec whose target contract is retired. I need exact severity, exact diagnostic id, and the file:line where it's emitted."
+
+### 4. Draft the page
+
+Use the `writing-clearly-and-concisely` skill's principles. The voice this project has settled on is:
+
+- **Lead with the answer.** First paragraph is the one-line distinction or the punchline. A reader who quits after one paragraph should still know the headline.
+- **Comparison table near the top.** When the page contrasts two things, put the table within the first screen so skimmers find it.
+- **Plain language over jargon.** Internal terms like "linter", "telemetry source label", "cross-contract rule", "DSL" are fine inside the implementation, but in user docs prefer "validation", "shows up in dashboards as", "rules that check the relationship", "the YAML format". Keep domain terms (contract, schema, primary key, dimension); drop tool internals.
+- **Hide the implementation; show the experience.** The reader is here to *use* the feature, not to learn how it's built. Do not name the JSON schema, the Pydantic model, the parser, the StrEnum, the specific lint rule code, the diagnostic id, the sentinel value, or the file:line that enforces something. Collapse all of that into what the user *sees*: "validation catches it", "the contract fails to load", "the CLI prints an error". Lint rule names are OK to mention once if the reader needs to grep for the diagnostic in their output, but never as a list of mechanisms ("the JSON schema enforces X, the lint rule does Y, the parser does Z"). Three sentences of plumbing become one sentence of behaviour.
+- **Two-tier layout for technical content.** When a page has unavoidable depth (full column tables, every field of a config struct, every status enum, dialect quirks, migration mechanics), do not dump it inline. The top of the page must read end-to-end for someone who is *not* implementing against it: prose, a diagram, and a one-line-each summary table. Push the column-by-column breakdowns and the "if you are debugging the writer" notes into mkdocs material collapsibles using `??? note "Section name"`. A reader who only wants the mental model can skim past; a reader who needs the rows can expand them. Use this layout especially on Concepts pages, where the audience is mixed.
+- **Diagrams over wall-of-prose for relationships.** Whenever a page describes objects that point at each other (database tables with FKs, components that exchange messages, lifecycle states), draw the picture. The docs site renders d2 — use ` ```d2 ` blocks with the project's `{{ d2_classes }}` macro and `{{ d2_edge }}` for arrows so the diagram inherits the dark-mode theme already configured in `mkdocs.yml` (`d2.dark_theme: -1`). For schema diagrams, use d2's `sql_table` shape (see `concepts/row-flagging.md` for an example). Do not reach for mermaid; the rest of the docs site is d2 and a stray mermaid block stands out. Mermaid is only acceptable if d2 genuinely cannot express what you need.
+- **Concrete examples in YAML block style.** Never inline flow style (`{key: value, key: value}`). Always indented blocks.
+- **No em-dashes.** Use commas, periods, or colons. The repo convention is strict.
+- **No agreement theater, no puffery.** No "groundbreaking", "seamless", "powerful", "the whole point", "stands as a testament". Say what the thing does and stop.
+- **Explain, don't sell.** If a sentence reads like marketing, cut it. If a sentence motivates a feature with pain ("Tired of brittle SQL tests?"), cut it.
+- **Reflect reality, even when it contradicts the existing doc.** If the existing page claims notifications, gates, or scoring behaviour the code does not implement, do not perpetuate it. Document the actual behaviour, and if the gap matters, mention it briefly without dressing it up.
+- **Short topic sentences. Short paragraphs. Lists when items are parallel.** Avoid the rule of three for its own sake.
+- **Active voice. Positive form. Definite, specific words.** Strunk's basics; the writing-clearly skill has the long version.
+
+Page skeleton that has been working:
+
+1. One-paragraph lead with the answer.
+2. "At a glance" table (only if the page is comparative or has a fixed set of slots).
+3. A diagram, if the page describes things that relate to each other (tables with FKs, lifecycle states, components calling each other). Use d2 with `{{ d2_classes }}`.
+4. The next thing the reader will want, usually "When to use which" or "What it looks like".
+5. Mechanics last: lint differences, runtime behaviour, edge cases. If any single section turns into a wide column table or a list of dialect quirks, push it into a `??? note "..."` collapsible so it does not break the reading flow above.
+6. "See also" cards block at the bottom, linking to neighbours.
+
+If the page exists already, prefer rewriting wrong sections in place over a top-down rewrite. The audit may have flagged three lines; a full rewrite throws away accurate prose.
+
+### 5. Wire up the nav (new page) or remove it (delete)
+
+For a **new page**, edit `docs/user/mkdocs.yml` and add the entry under the right section. The order in the nav usually matches the doc's intended position in a learning sequence; ask if unsure.
+
+For a **delete**, remove the nav entry, remove any redirects in `mkdocs.yml`'s `redirect_maps` pointing at the deleted file, and check there are no internal links to it (`grep -rn 'reference/comparison'` or similar). Fix or drop any orphaned links.
+
+### 6. Dispatch the reviewer
+
+Spawn a subagent to verify the draft against the code. Use the `general-purpose` agent (the `spec-reviewer` agent is for code-vs-spec compliance, not docs-vs-code; this is the closest fit for verification work).
+
+Reviewer prompt template:
+
+```
+Verify that the documentation page at <path> accurately describes the
+behaviour of <feature> in this codebase.
+
+What I changed/wrote: <one-paragraph summary>.
+
+Read the page, then read the actual implementation in <list of files
+you checked in step 3>. For every factual claim in the page (CLI flags,
+YAML field names, default values, error severities, runtime behaviour,
+lint rule names), confirm it against the code or flag it as wrong.
+
+Also flag:
+- Claims of features that do not exist in code.
+- Stale terminology (renamed enums, fields, modules).
+- YAML examples that would not parse against the current Pydantic models.
+
+Report findings as a numbered list. For each finding give: the line in
+the doc, what it claims, what the code actually does, and the file:line
+that proves it. Do not rewrite the doc; just report. Under 400 words.
+```
+
+### 7. Apply the fixes
+
+Read the reviewer's findings. For each one:
+
+- If the finding is correct, fix the doc.
+- If the finding is wrong (rare, but happens when the reviewer reads stale code in another worktree), say so and move on.
+
+Do **not** silently accept findings without checking. Reviewers occasionally over-correct.
+
+### 8. Tick the box
+
+Edit `docs-todo.md`. Change the `- [ ]` for this item to `- [x]`. Do not change other lines.
+
+### 9. Report back
+
+Tell the user:
+
+- Which item you took.
+- Whether it was a new page, update, or delete.
+- The 2–4 most material reality-vs-doc gaps you closed (skip trivial typos).
+- The path of the file you wrote, so they can open it.
+- That the box is ticked.
+
+Stop there. Do not auto-advance to the next item; the user decides when to run again.
+
+## Things that have tripped this workflow before
+
+- **Following audit hints blindly.** The audit was made on a date; some hints are no longer accurate. Always re-verify.
+- **Carrying over salesy phrasing from the old doc.** If the previous page said "ensures rock-solid quality across your entire data platform", do not preserve that voice for continuity. Rewrite it plain.
+- **Adding em-dashes back in.** They sneak in via copy-paste from the old doc. Grep the final file for `—` and remove every one before committing.
+- **Restating schema in QualitySpec docs (or similar).** Specs inherit from the contract; do not re-document the schema in two places.
+- **Listing internal mechanisms when one user-facing sentence will do.** A draft that reads "the JSON schema enforces the enum, the `check-dimension-required` lint rule errors out when missing, and the `--min-score` parser rejects unknown names" leaks three implementation details the reader does not care about. Replace with "validation catches it" or "the contract fails to load". The reader wants to know what they will experience, not which layer caught them. Same for sentinel keys, parser fallbacks, and "shouted about it" asides about lint behaviour — they're plumbing, not user surface.
+- **Dumping every column inline.** A schema page with five tables, each with eight to ten columns, becomes a wall of grids that drowns the prose. Lead with the mental model (what each table is *for*, in one line) and a diagram, then collapse the per-column tables into `??? note "<table name>"` blocks. A reader who only needs the diagram never has to scroll past the schema; a reader who needs the columns expands them. This applies whenever a page would otherwise carry more than one wide reference table.
+- **Editing the changelog.** This skill does not touch `CHANGELOG.md`. If the user wants a changelog line, that is a separate ask.
+
+## What this skill does not do
+
+- It does not commit or push. The user runs `/commit` when they're ready.
+- It does not run the docs build. If the user wants a preview, they run `mkdocs serve --livereload` themselves.
+- It does not advance to the next item automatically.

turbine_data-0.1.0/.git

@@ -0,0 +1 @@
+gitdir: /Users/yassin/Documents/projects/turbine/.git/worktrees/turbine-lsp

turbine_data-0.1.0/.gitignore

@@ -0,0 +1,69 @@
+# Turbine metadata
+.turbine/
+
+# Intentionally broken example files (for manual error testing)
+example_errors/
+
+# Environment variables
+.env
+
+# Python
+__pycache__/
+*.py[cod]
+*$py.class
+.pytest_cache/
+.complexipy_cache/
+*.egg-info/
+dist/
+build/
+_version.py
+
+# DuckDB
+*.duckdb
+*.duckdb.wal
+
+# Node
+node_modules/
+*.vsix
+
+# IDE
+.idea/
+.vscode/
+*.swp
+*.swo
+
+# Gradle / JetBrains plugins
+.gradle/
+.intellijPlatform/
+example/datasources/datasource_snowflake.yml
+.coverage
+
+# Claude Code
+.claude/settings.local.json
+.claude/worktrees/
+.audit-workspace/
+claude-docs/
+**/.DS_Store
+.cache
+site
+.playwright-mcp
+
+# Architecture site generated output
+docs/contributing/architecture/build/
+
+# E2E test output
+e2e-output/
+hidden
+ab_presentation
+tach_module_graph.dot
+TODO.md
+.strikt_cache
+.understand-anything
+demo/keys/snowflake_key.pem
+_legacy/
+slides
+refactor-paths.md
+plan.md
+meeting-context.md
+parity-todo.md
+.preview-cache

turbine_data-0.1.0/.gitlab-ci.yml

@@ -0,0 +1,36 @@
+include:
+  - project: 1000009-python-platform/applications/pipelines/uv
+    file: python-3.12.yml
+    inputs:
+      renovate-repositories:  "1000078-app-keten-shared/applications/turbine-container"
+
+publish-pypi:
+  stage: build
+  image: $CI_REGISTRY/1000009-python-platform/applications/containers/python_ci:1.0.22-3.12
+  tags:
+    - linux
+  needs: []
+  script:
+    - uv build
+    - uv publish --token "$PYPI_TOKEN"
+  rules:
+    - if: $CI_COMMIT_TAG
+
+publish-vscode-marketplace:
+  stage: build
+  image: node:22-bookworm
+  tags:
+    - linux
+  needs: []
+  script:
+    - cd editors/vscode
+    - npm ci
+    - npm run package
+    - npm run publish:marketplace -- -p "$VSCE_PAT"
+  artifacts:
+    when: always
+    paths:
+      - editors/vscode/*.vsix
+    expire_in: 1 week
+  rules:
+    - if: $CI_COMMIT_TAG