Dander

[!WARNING] Beta software. Dander has completed source-free candidate acceptance and continues through a operator trial. Use a disposable GCP project, review every Terraform plan, and read the known limitations before relying on it. Only the latest patch in the current 0.x minor is supported.

An opinionated, self-hosted, GCP-native data platform you own — ingest + transform + catalog behind one CLI. A focused replacement for Informatica and a customizable stand-in for dbt.

Think "Terraform for your data platform." dander init stands up the GCP infrastructure; dander run extracts your SaaS systems into BigQuery; the transform engine models the data; and a single metadata spine keeps your catalog and semantic layer in sync.

Why it exists

Every existing tool does one slice: dlt ingests, dbt transforms, Airbyte/Meltano are platforms but heavy or bring-your-own-everything. None ship an opinionated, self-hosted, GCP-native system that fuses ingest + transform + catalog and that a small team fully owns — no per-row bill, no vendor-consolidation risk. That's the gap dander fills.

The wedge — what makes it different

1. Batteries-included + self-provisioning. One CLI provisions Secret Manager, IAM/WIF, Cloud Run, and BigQuery, then runs your pipelines.
2. Enterprise SaaS auth as a first-class citizen. Workday RaaS, NetSuite OAuth1 TBA, Xactly — the connectors that are painful everywhere else, as vetted, typed auth strategies.
3. A single metadata spine. One YAML per model/source projects to SQL and your data catalog (Dataplex aspects) and a semantic/agent registry. Define once, project everywhere.
4. You own all of it. Open source, customizable, GCP-opinionated.

Architecture

Hybrid ingestion (dlt for standard REST APIs, hand-rolled extractors for gnarly enterprise sources — both behind one Source interface) → explicit, idempotent BigQuery write patterns → our own transform engine (ref() DAG → topological execution + tests) → catalog publication. See steering/00-project-overview.md for the full module map and decision log.

Repository checks and branch-protection guidance live in docs/ci.md. The approval-gated, WIF-authenticated live proof is documented in docs/live-proof.md; keep the pull request draft until its sanitized workflow artifact is reviewed.

Operator-facing documentation:

• Hosted Greenhouse quickstart
• Upgrades and safe reruns
• Known limitations
• Post-release operator soak
• Security and supported versions
• Release notes

Stack

Python 3.12 (app + CLI) · BigQuery SQL (transforms) · Terraform/HCL (infra) · YAML (config).

Install the current public release

The Python distribution is named dander-platform because the dander name on PyPI belongs to a different project. The import package and command remain dander:

uv tool install dander-platform==0.9.0rc11
dander --version
dander new my-data-platform
cd my-data-platform
dander validate

dander new creates a complete, paused starter project: a public Greenhouse connector, one model, the Docker runtime context, and Dander's Terraform modules. It refuses to overwrite an existing path. You do not need to clone this repository to use the released CLI. Follow the hosted quickstart to provision and manually verify the paused Greenhouse pipeline before enabling its schedule.

Repo map

src/dander/     core · security · ingestion · writer · executor · transform · catalog · state · cli
infra/          Terraform modules (secret-manager, iam, compute-run, bigquery)
connectors/     per-source YAML configs
models/         SQL transform models + YAML sidecars
tests/
steering/       binding rules for humans + agents (read these)
tickets/        work items
scripts/        dev tooling (e.g. the workflow monitor)
.claude/        agent workforce, feature workflow, /feature command

Developer setup (macOS)

Prerequisites

• Homebrew
• uv — manages the Python toolchain and dependencies (it will fetch Python 3.12 itself, so you don't need to install Python separately)
• git
• Claude Code — only if you want to run the agentic /feature workflow (see below). Not needed to build or test the Python package.

Install

brew install uv                 # one-time: install uv
git clone <repo-url> dander && cd dander
uv sync --extra dev             # install app + dev deps into .venv (fetches Python 3.12 if needed)

That's it — uv sync creates the virtualenv, installs everything from pyproject.toml, and pins it in uv.lock.

Everyday commands

All commands run through uv run (no need to activate the venv manually):

uv run ruff check .        # lint
uv run ruff format .       # auto-format
uv run mypy                # strict type-check
uv run pytest              # run the test suite
uv run dander --help       # the CLI (init / run)
uv run dander validate     # validate dander.yaml and every pipeline reference
uv run dander metadata list --project my-gcp-project

Green baseline = ruff check, ruff format --check, mypy, and pytest all pass. Keep it green; the pr-review agent enforces it on every ticket.

Runnable Greenhouse paths

The free first path reads published jobs from Greenhouse's public Job Board API. It uses Greenhouse's own board as a live example, needs no Greenhouse account or credential, and exercises the same dlt → BigQuery writer path as private connectors:

uv run dander run greenhouse_job_board --dry-run --project my-gcp-project
uv run dander run greenhouse_job_board --guarded-free-tier --project my-gcp-project

To read another organization's published jobs, copy the connector and replace greenhouse in /greenhouse/jobs with the public board token from its job-board URL. Public GET requests return published job data only; they do not expose candidates, applications, or other private records.

Additional real public job boards

lever_job_board reads Spotify's published Lever postings and exercises the provider's skip/limit pagination. ashby_job_board reads Ashby's published jobs, including publicly displayed compensation where present. Both are credential-free, read-only examples using official public APIs:

uv run dander run lever_job_board --dry-run --project my-gcp-project
uv run dander run ashby_job_board --dry-run --project my-gcp-project

See the official Lever Postings API and Ashby Job Postings API documentation. Public boards can change or migrate without notice; copy the connector and replace the documented site/board token to target another organization's published jobs.

Deterministic fault injection

The local synthetic vendor remains the repeatable test for behavior that must not be provoked against public services: duplicate/update scenarios and deterministic 429/500 recovery.

uv run dander-synthetic-api
uv run pytest tests/ingestion/test_synthetic_vendor.py

Do not use public profiles as substitute candidate data. Candidate- or contact-shaped integration tests should contain invented people in an account you control. HubSpot offers free developer test accounts with sample CRM data; connecting one requires the account owner to create and authorize the test app, so no credential or account is embedded in this repository.

The canonical greenhouse connector reads private candidates and jobs through Harvest v3. It uses OAuth 2.0 client credentials, caches expiring access tokens, and applies the token to every paginated request. Export the two credential references locally, or point each environment value at a full Secret Manager version resource in cloud execution:

read -r SECRET_GREENHOUSE_CLIENT_ID
read -rs SECRET_GREENHOUSE_CLIENT_SECRET && printf '\n'
export SECRET_GREENHOUSE_CLIENT_ID SECRET_GREENHOUSE_CLIENT_SECRET
uv run dander run greenhouse --project my-gcp-project

Create Harvest v3 credentials in Greenhouse under Configure → Dev Center → API Credential Management, choose Harvest V3 (OAuth), and grant only the read scopes for candidates and jobs. By default Greenhouse attributes requests to the integration service user associated with the credential. An optional integer auth_options.subject can select a different Greenhouse user. See Greenhouse's v3 authentication guide.

greenhouse_harvest_v1_legacy preserves API-key compatibility during migration only. Greenhouse states that Harvest v1/v2 become unavailable after 2026-08-31; new deployments should not use it.

connectors/marketo.example.yaml is the second standard-REST template. Copy it to connectors/marketo.yaml, replace MUNCHKIN_ID, and provide the two named secret references. It follows Adobe's current two-legged OAuth token shape, sends API access tokens in the Authorization header, pages the read-only Programs endpoint, and enforces the documented five-request-per-second instance rate. See Adobe's authentication guide for the tenant-side custom-service setup.

Hand-rolled Workday path

WorkdayRaasSource proves the second half of the hybrid-ingestion design without dlt. Copy connectors/workday_raas.example.yaml, supply your tenant/report identifiers and secret references, then run it through the same CLI/runtime/writer path. The source owns page-number pagination, cursor parameters, bounded backoff, response-envelope validation, and declared BigQuery scalar casts. Its complete test suite uses an injected fake transport; no Workday credential or employee row is stored in this repository.

Enterprise authentication templates

connectors/salesforce_jwt.example.yaml is a complete read-only CRM slice for Accounts, Contacts, Opportunities, and Users: OAuth2 JWT authentication, bounded streaming Bulk API 2.0 result pages, declared raw schemas, and independent inclusive SystemModstamp watermarks. QueryAll retains Account, Contact, and Opportunity tombstones; User deactivation is represented by IsActive. Contact Email and Phone are personal data enabled by default. Dander supports the independently installed first-party dander-connector-salesforce plugin; an exact manifest pin takes precedence over the deprecated built-in fallback. See docs/salesforce.md.

Connector authors can start with dander plugins scaffold and the focused plugin-authoring guide. The generated package uses Dander's API-v1 conformance helpers and remains inactive until a project pins its exact version.

connectors/servicenow.example.yaml reads incidents through ServiceNow's Table API using OAuth2 client credentials, primitive internal values, stable offset paging, and a declared raw schema. The first slice performs a full read and idempotent SCD1 publication; it does not claim unsafe timestamp-plus-offset incrementality. See docs/servicenow.md.

connectors/odoo.example.yaml reads Odoo 19+ contacts and companies through the current JSON-2 API using a bearer API key, bounded pages, and an inclusive write_date watermark. Odoo Online requires a Custom plan for external API access; the official Odoo Community Docker image provides a free local development target. See docs/odoo.md.

connectors/netsuite.example.yaml is a simulator-validated, not NetSuite-validated customer SuiteQL slice. It uses bounded offset paging, stable ordering, declared schemas, and the existing OAuth1 TBA signer. It is not part of the current public support surface; real-tenant acceptance and current OAuth2 setup remain gates for a future release. See docs/netsuite-simulator.md.

Strict $0 BigQuery Sandbox

For evaluation without a billing account, create a BigQuery Sandbox project, authenticate Application Default Credentials, then run the public connector:

gcloud auth application-default login
uv run dander run greenhouse_job_board --sandbox --project my-no-billing-project

--sandbox fails closed unless the Cloud Billing API explicitly reports that billing is disabled. It creates the raw dataset without Terraform, resolves secrets from the environment only, replaces each destination through a WRITE_TRUNCATE load job, and stores observed cursors in .dander/state.db. Every sandbox run is a full refresh because BigQuery Sandbox does not support DML, including MERGE. It does not use Secret Manager, GCS, Cloud Run, or other services whose free tiers require a billing account. If Cloud Billing returns an authorization/API error, Dander does nothing; enable API access or fix the caller's read permission, then retry.

The public connector, dry runs, local tests, and all fake-provider tests need no external credentials. Harvest v3 still requires access to a Greenhouse customer account:

uv run dander run greenhouse_job_board --sandbox --dry-run --project my-no-billing-project

Billing-linked hosted platform and optional cost guard

To exercise the real Secret Manager, BigQuery MERGE, and BigQuery watermark path, use an existing project with billing already linked. The managed cost guard and its project-scoped budget are optional. Google currently provides monthly free usage for the first 10 GiB of BigQuery storage and 1 TiB of analysis, six active Secret Manager versions and 10,000 accesses, and bounded Cloud Run compute and request usage. These are usage allowances, not a promise that the project cannot incur charges.

Create the project-scoped budget (the project filter is important):

gcloud billing budgets create \
  --billing-account="$BILLING_ACCOUNT_ID" \
  --display-name="dander-sbx-cap" \
  --budget-amount=5.00USD \
  --filter-projects="projects/$PROJECT_ID" \
  --threshold-rule=percent=0.8,basis=current-spend \
  --threshold-rule=percent=1.0,basis=current-spend \
  --notifications-rule-pubsub-topic="projects/$PROJECT_ID/topics/dander-stop-billing"

Follow Google's programmatic notification setup and billing-disable tutorial to deploy infra/functions/stop_billing using the topic dander-stop-billing. Always deploy it with SIMULATE_DEACTIVATION=true, publish a synthetic over-budget event, and inspect the simulation log before switching it to false. Provider-managed trigger subscription names are supported. Then run:

export SECRET_GREENHOUSE_CLIENT_ID='projects/PROJECT/secrets/greenhouse-client-id/versions/latest'
export SECRET_GREENHOUSE_CLIENT_SECRET='projects/PROJECT/secrets/greenhouse-client-secret/versions/latest'
uv run dander run greenhouse --guarded-free-tier --project "$PROJECT_ID"

Before reading the secret or extracting data, Dander requires billing enabled, the named project-scoped USD budget at or below $5, 80% and 100% current-spend thresholds, the expected Pub/Sub topic, and at least one attached subscription. This verifies configuration metadata; it cannot prove the subscriber's code or runtime health. Google says budgets do not cap spending, notifications are emitted several times daily, and charges can arrive after billing is detached. The kill switch can stop services and make resources unrecoverable. Set the budget below the actual amount you could tolerate and use a dedicated disposable project.

New users may instead use the $300/90-day Free Trial. While the account remains a Free Trial account, Google says usage is not charged to the payment method; manually upgrading makes overages beyond remaining credit and free allowances billable.

dander init and dander init --apply remain compatible shortcuts. The documented installation path separates each mutation from its saved Terraform plan: create the state bucket once, run init-admin-plan, review and run init-admin-apply, publish an immutable source-free image with image-publish, then run init-platform-plan, review, and run init-platform-apply. See the hosted quickstart for copyable commands. Newly generated projects keep portable pipeline intent in dander.yaml and GCP deployment settings in dander.platforms.yaml. The standard deployment uses the ordinary hosted path without the optional managed cost guard:

deployments:
  gcp_cloud_run:
    platform: gcp
    launcher:
      provider: cloud_run
      region: us-central1
    safety:
      require_guarded_free_tier: false

The deployment's repository-owned runtime values configure every hosted job. batch_rows bounds both hosted SCD1 extraction batches and BigQuery writer requests. Sandbox replacement also consumes the endpoint as bounded batches through a run-scoped staging table. When guarded free tier is required, initialization rejects a disabled cost guard and hosted jobs receive --guarded-free-tier. The --region, --bigquery-location, --runtime-*, and guarded-free-tier override flags take precedence only when explicitly supplied. The cost guard defaults to enabled when require_guarded_free_tier is true and disabled when it is false; explicit cost-guard flags can override that default when the combination is valid.

The standard installer does not need Project Owner. The one-time stage-zero bundle is Service Usage Admin, Storage Admin, Artifact Registry Administrator, Service Account Admin, and Project IAM Admin. A cloud administrator can perform that step and grant the operator Service Account Token Creator only on Dander's bootstrap account; image publication and later platform plans then use that account through impersonation. GitHub WIF additionally requires Workload Identity Pool Admin. Terraform never receives secret values. Add each named value after bootstrap with gcloud secrets versions add, then execute a paused pipeline manually before enabling its schedule. --failure-alert-email is an operator input rather than a manifest field, so personal addresses stay out of public repositories; repeat it on later reconciliations to retain the email channel and per-pipeline Cloud Run failure policies.

Every plan command prints its saved-plan location and exact apply command. Every apply command applies only that saved plan after confirmation. The approved administrative identity is separate from runtime identities; only it can provision project resources. Guarded installations additionally use it to delegate each runtime's read-only billing visibility. The default unguarded path does not request billing-account IAM or grant runtime billing/Pub/Sub guard permissions. Dander does not manage, limit, or prevent cloud spending in that configuration. To opt into the managed guard, set deployments.gcp_cloud_run.safety.require_guarded_free_tier: true and pass --billing-account ABCDEF-123456-ABCDEF; the caller then needs the additional billing-account permissions required for the reviewed IAM and budget plan.

For an established environment, produce the complete manifest-aware plan with:

uv run dander init-platform-plan \
  --project my-gcp-project \
  --state-bucket my-existing-tfstate-bucket \
  --bootstrap-service-account dander-bootstrap@my-gcp-project.iam.gserviceaccount.com \
  --container-image us-central1-docker.pkg.dev/my-gcp-project/dander/dander@sha256:DIGEST \
  --config dander.yaml \
  --failure-alert-email operator@example.com

The image must use an immutable SHA-256 digest. In new projects, dander.yaml declares logical pipelines and dander.platforms.yaml declares schedules, secret references, resources, and the selected providers. Version 1 combined manifests remain supported during the compatibility window; dander config migrate --check proves the deterministic split before dander config migrate writes it. See platform profiles. Secret Manager containers and per-pipeline runtime access are managed by Terraform, but secret values never enter the manifest or Terraform state. GitHub Actions authenticates through repository/ref-constrained OIDC rather than a downloaded key. Set publish_dataplex: true only on pipelines that should store catalog aspects; it enables the API and IAM required for that potentially billable operation. The optional integrated cost guard creates the project budget, Pub/Sub wiring, and Gen 2 function in simulation mode. Live billing detachment requires the additional --live-cost-guard flag and is called out in the apply confirmation. Function deployment uses billable Cloud Build, Cloud Run, Storage, and Artifact Registry services; free allowances do not make this a hard $0 guarantee.

Optional hosted Druff interface

Dander can provision Druff's compiled interface beside the hosted pipelines without exposing a graph or execution API to the internet. Build and push Druff's production Dockerfile, resolve its immutable digest, and include it in every full-platform plan that should retain the interface:

uv run dander init \
  --project my-gcp-project \
  --container-image us-central1-docker.pkg.dev/my-gcp-project/dander/dander@sha256:DANDER_DIGEST \
  --druff-container-image us-central1-docker.pkg.dev/my-gcp-project/dander/druff@sha256:DRUFF_DIGEST

Terraform creates a public, scale-to-zero Cloud Run service with a dedicated service account that has no project roles. The hosted page contains no connector credentials, graphs, or cloud control plane. Public requests can still create Cloud Run usage and charges; the one-instance ceiling limits capacity but is not a spending cap. From the operator's project checkout, connect it to one local graph explicitly:

dander graph serve \
  --file /absolute/path/to/graph.yaml \
  --origin https://DANDER-DRUFF-CLOUD-RUN-URL

The browser may ask for local-network access before contacting 127.0.0.1. Dander still owns the graph file, validation, save conflicts, and any operator-bound execution. Omitting --druff-container-image from a later full-platform plan deliberately plans removal of the hosted interface; pass the same digest to retain it. A deployment preview started from Druff likewise needs that flag so its full-platform plan preserves the service.

Additive hosted pipelines

The tracked dander.yaml runs Greenhouse, HubSpot, Salesforce, and ServiceNow as separate daily pipelines, plus one paused executable Greenhouse graph. Each pipeline receives its own Cloud Run Job, Scheduler trigger, runtime identity, scheduler identity, secret bindings, model selection, and pause policy. They share the immutable image and BigQuery datasets. Adding a pipeline never repurposes another pipeline's job. Salesforce and ServiceNow are supplied by exact plugin pins in the retained source-free project.

uv run dander validate
uv run dander run greenhouse_jobs --dry-run --project my-gcp-project
uv run dander run hubspot_companies --dry-run --project my-gcp-project
uv run dander run salesforce_accounts --dry-run --project my-gcp-project
uv run dander run servicenow_incidents --dry-run --project my-gcp-project

Provision or reconcile every declared pipeline from the manifest:

uv run dander init --project "$PROJECT_ID" --apply
gcloud run jobs execute dander-hubspot-companies --region=us-central1 --wait

After a new pipeline's manual ingestion, transform tests, and registry compilation succeed, set its paused field to false, review a fresh saved plan, and apply that exact plan. The image repository deletes untagged images after one day and retains the three most recent versions. A small number of Scheduler jobs and Cloud Run executions may fit current free allowances, but those allowances are not a hard spending cap. The guarded CLI preflight and budget kill switch remain available through the explicit safety opt-in described above.

Declared raw schemas

Every endpoint used by a pipeline in dander.yaml declares its complete raw BigQuery schema in the connector. The declaration is recursive and supports NULLABLE, REQUIRED, and REPEATED fields, including nested RECORD fields:

endpoints:
  - name: companies
    path: /crm/v3/objects/companies
    primary_key: [id]
    raw_schema:
      - name: id
        type: INT64
      - name: properties
        type: RECORD
        fields:
          - name: name
            type: STRING

Before loading, Dander recursively rejects undeclared fields and invalid structural or scalar types, fills missing nullable fields with null, and fills missing repeated fields with []. An empty first extraction creates the raw table directly from the declaration, so hosted sources do not need synthetic seed rows.

Hosted SCD1 execution compares the declaration with the deployed table before loading. It may add only missing, explicitly declared top-level NULLABLE fields. New nested fields, deployed-only fields, type changes, mode changes, and removals fail before a load begins. Tables created by an older inference-based release may therefore need an operator-reviewed migration or rebootstrap; Dander will not guess a destructive conversion. Running a connector directly without dander.yaml may still omit raw_schema for compatibility, but that inference path is deprecated.

Concurrency and cursor safety

Every named pipeline acquires one exclusive lease before extraction. Hosted runs keep that lease in dander_meta._dander_leases; sandbox runs use .dander/state.db. A second invocation records a terminal skipped run instead of overlapping the active owner. Heartbeats renew the lease, and a run that cannot renew fails closed before its next write, transform, or metadata publication.

Each successful acquisition receives a monotonically increasing fencing token. BigQuery DML finalizers conditionally update the matching pipeline ID, run ID, and token inside the same transaction as target mutation; a read-only lease check is not sufficient. Cursor commits use compare-and-set against the watermark read before extraction and perform that same fenced lease touch in hosted execution. A stale run can therefore neither publish a DML finalizer nor advance a newer run's cursor. Sandbox replace remains atomic but is not claimed as transactionally fenced cloud publication.

Build and test SQL models

Every SQL model has a YAML sidecar that defines its materialization, catalog metadata, columns, and generic tests. Dander validates the complete project, resolves ref() dependencies, orders models, compiles one read-only BigQuery query per model, materializes views or tables, and then runs the declared assertions:

uv run dander build \
  --project "$PROJECT_ID" \
  --select stg_greenhouse__jobs \
  --guarded-free-tier

uv run dander test \
  --project "$PROJECT_ID" \
  --select stg_greenhouse__jobs \
  --guarded-free-tier

Repeat --select to build multiple roots; their model dependencies are included automatically. Omit it to build every model. References beginning with raw_ resolve by convention to raw.<remaining_name>; other references must name a discovered model. Unknown references, cycles, missing/invalid sidecars, non-query SQL, and unsupported incremental materializations fail before the first BigQuery query. Generic tests currently support not-null, unique, accepted-values, and relationships.

Inspect the metadata spine

Every named dander run atomically replaces its pipeline snapshot in dander_meta._dander_catalog after transforms and tests pass. The snapshot contains source endpoints, models, columns, lineage, tests, and governed metric calculations; the same run writes its complete lifecycle outcome to dander_meta._dander_runs.

uv run dander metadata list --project "$PROJECT_ID"
uv run dander metadata show published_job_count --project "$PROJECT_ID"
uv run dander metadata lineage stg_greenhouse__jobs --project "$PROJECT_ID"
uv run dander metadata metrics --project "$PROJECT_ID"
uv run dander metadata runs --project "$PROJECT_ID"

The same model sidecar can also project into a deterministic file and optional Dataplex Knowledge Catalog aspects:

uv run dander catalog \
  --project "$PROJECT_ID" \
  --select stg_greenhouse__jobs \
  --output .dander/catalog.json

Local compilation is the default. --publish-dataplex explicitly attaches the optional overview, contacts, and generic system aspects to the corresponding BigQuery entry; BigQuery's required schema aspect remains Google-managed. It can be combined with --guarded-free-tier, and publication never deletes unrelated aspects. Google currently makes Knowledge Catalog API calls free but charges for stored aspect metadata, so cloud mutation is not implicit. See Knowledge Catalog pricing and Dataplex aspect management.

Current v0 limits are collected in the known-limitations page. The tracked implementation ledger remains in docs/spec-alignment.md.

The agent workforce & the /feature workflow

Features are built by a workforce of agents defined in .claude/ — the feature workflow runs the loop Product → Design → Code → PR-Review, looping a ticket back to Code with an addendum until it passes review. See CLAUDE.md for the full picture.

First, register it. .claude/agents/, .claude/workflows/, and .claude/commands/ are loaded only at Claude Code startup. After cloning (or after editing anything under .claude/), restart Claude Code in the project root so /feature, the agents, and the feature workflow become available. Run "/config workflows=true" in a Claude chat window to enable it for that session.

Then run it (any of these — it costs tokens, so each run is an explicit opt-in):

/feature Add an ApiKeyBasic auth strategy and wire GcpSecretStore

(or just ask Claude in chat)   run the feature workflow with: <describe the feature>

# headless / scripted, from a terminal:
claude -p --permission-mode acceptEdits "run the feature workflow with args: <describe the feature>"

It writes tickets to tickets/ (lifecycle open → in-design → in-code → in-review → done), implements + reviews each until PASS, and leaves the code + tests in your working tree.

Watching workflows in real time

A workflow run spawns many background agents. scripts/watch_workflows.py is a dependency-free (stdlib-only) live dashboard — run it in a separate terminal while a workflow is going:

python3 scripts/watch_workflows.py          # live dashboard, refresh every 2s
python3 scripts/watch_workflows.py --all    # include finished / idle runs
python3 scripts/watch_workflows.py -n 5     # refresh every 5s
python3 scripts/watch_workflows.py --once   # print one snapshot and exit

It auto-discovers all runs across sessions (so it handles several concurrent workflows), and shows each run's agents with their role, ticket, and live PASS/FAIL verdicts:

● wf_020b226b-07f  RUNNING  elapsed 13m48s  agents 7 done
   ✓ product       —         2 ticket(s)
   ✓ design        DANDER-2  design ready
   ✓ code-python   DANDER-2
   ✓ pr-review     DANDER-2  PASS
   ▸ pr-review     DANDER-3  working…

Status

Dander 0.9.0rc11 is the current public beta: its source-free GCP platform, connector plugins, transform/test engine, run ledger, metadata spine, and Druff operator interface have completed bounded live proofs. It remains pre-1.0 software; review the documented limitations before using business-critical data. The named HR, compensation, and customer systems describe connector categories or bounded test implementations; they do not imply that this repository came from, connects to, or contains data from an existing company. Normal provenance, licensing, and privacy review still applies before adding employer-owned code or non-public data.

For the latest dated release, validation, retained-project, and next-session snapshot, see docs/session-resume.md.

License

Apache-2.0.