run-dbt 0.1.0__tar.gz

run_dbt-0.1.0/.gitignore

@@ -0,0 +1,224 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+.planning/
+
+# PDT runtime and test files
+.pdt/
+test_workspace/
+mock_llm.py

run_dbt-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 pdtdotdev
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

run_dbt-0.1.0/PKG-INFO

@@ -0,0 +1,157 @@
+Metadata-Version: 2.4
+Name: run-dbt
+Version: 0.1.0
+Summary: Process Deploy Tool: Git-native runtime for state-bounded operational AI workflows.
+License: MIT
+License-File: LICENSE
+Keywords: ai-agents,cli,dev-tools,infrastructure,workflow-automation
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.11
+Requires-Dist: click>=8.0.0
+Requires-Dist: fastapi>=0.136.3
+Requires-Dist: google-genai>=2.8.0
+Requires-Dist: markdown-it-py>=4.2.0
+Requires-Dist: pydantic>=2.13.4
+Requires-Dist: rich>=15.0.0
+Requires-Dist: ruamel-yaml>=0.19.1
+Requires-Dist: typer>=0.26.7
+Requires-Dist: uvicorn>=0.49.0
+Description-Content-Type: text/markdown
+
+# PDT (Process Deploy Tool)
+
+> **Git-native runtime for state-bounded operational AI workflows.**
+
+`pdt` is a developer-focused Command Line Interface (CLI) and runtime engine designed to govern, parse, lint, and execute standard-conforming **`PROCESS.md`** files. 
+
+Inspired by analytics engineering tools like `dbt`, `pdt` decouples general-purpose LLM capabilities (**skills**) from operational business logic and policies (**processes**). It provides deterministic execution boundaries, step-by-step state preservation, and human-in-the-loop (HITL) gates.
+
+---
+
+## Core Philosophy: Workflow Engineering
+
+Most operational teams do not need another open-ended autonomous agent. They require a reliable framework to transform recurring, high-stakes business processes into structured, version-controlled workflows. 
+
+PDT establishes this via **Workflow Engineering**—pairing deterministic execution structures with bounded model reasoning:
+* **Decoupled Skills & Processes**: Skills describe *how* to perform a reusable task (general/mechanical); processes describe *what* should happen, in what order, and under what constraints (contextual/governing).
+* **Markdown as Code**: `PROCESS.md` files are the "SQL of operations"—readable by non-developer process owners, versioned in Git, and executable by a computer.
+* **Deterministic Bounding**: Instead of letting an LLM navigate a workflow in an open-ended loop (resulting in unpredictable execution costs and loops), the PDT runtime runs one isolated step at a time, enforcing boundaries and security.
+* **Human-Centered Exceptions**: When exceptions or gates are hit, the runtime halts, saves state, and alerts humans to verify or approve the execution.
+
+---
+
+## Workspace Layout
+
+A conforming PDT workspace is organized as follows:
+
+```text
+/workspace
+├── pdt.yaml                          # Workspace configuration
+├── processes/                        # Executable workflows
+│   └── growth_experiment_review/
+│       └── PROCESS.md
+├── skills/                           # Capability guides
+│   └── experiment-analysis/
+│       └── SKILL.md
+├── tools/                            # Code execution units
+│   └── experiment_lookup/
+│       ├── tool.yaml
+│       └── main.py
+└── schemas/                          # Data validation contracts
+    └── experiment-summary.schema.json
+```
+
+---
+
+## Anatomy of `PROCESS.md`
+
+An executable SOP contains three main components:
+
+```markdown
+---
+id: growth_experiment_review
+name: Growth Experiment Review
+version: 0.1.0
+owner: growth-team
+status: active
+runtime: pdt.process.v0
+---
+# Description
+A workflow to review growth experiments, aggregate conversions, and perform high-level evaluation before approval.
+
+# Workflow
+## Step 1: Load active experiments
+Lookup all active experiments using the tool `tool/experiment_lookup`.
+
+## Step 2: Assess statistical performance
+Evaluate the total conversion metrics using `skill/experiment-analysis` and construct a structured JSON summary matching `schema/experiment-summary`.
+
+## Step 3: Approve experiment
+Review the assessment and request final business approval before closing.
+```
+
+---
+
+## CLI Commands & Usage
+
+Install the PDT package:
+```bash
+pip install run-dbt
+```
+
+### 1. `pdt init`
+Initialize a new standard workspace directory layout with default configuration:
+```bash
+pdt init [workspace_path]
+```
+
+### 2. `pdt lint`
+Validate workspace config, verify step index ordering, and resolve all inline reference links to confirm they point to valid skills, tools, processes, and schemas:
+```bash
+pdt lint processes/growth_experiment_review/PROCESS.md
+```
+
+### 3. `pdt parse`
+Parse a `PROCESS.md` file and output a clean Abstract Syntax Tree (AST) in JSON format:
+```bash
+pdt parse processes/growth_experiment_review/PROCESS.md
+```
+
+### 4. `pdt run`
+Execute the workflow steps sequentially. PDT automatically runs local tools, saves evidence, compiles bounded prompts, and pauses when a human gate (e.g. "approval") is encountered.
+
+* **Execute workflow fully:**
+  ```bash
+  pdt run processes/growth_experiment_review/PROCESS.md --input metrics.json
+  ```
+* **Run a single step only:**
+  ```bash
+  pdt run processes/growth_experiment_review/PROCESS.md --step 2
+  ```
+* **Resume a paused workflow:**
+  ```bash
+  pdt run --resume run_98a72f1c
+  ```
+
+### 5. `pdt deploy`
+Package the workspace and generate container/deployment configurations:
+```bash
+pdt deploy --target docker --dry-run
+```
+
+---
+
+## Webhook Server Daemon
+
+Deploy the workspace as a serverless runtime using the built-in FastAPI daemon:
+```bash
+uvicorn pdt_cli.server:app --port 8080
+```
+This exposes REST API endpoints to trigger and manage workflows remotely:
+* `POST /run/{process_id}`: Trigger step execution with input payload.
+* `GET /status/{run_id}`: Check status and inspect run evidence.
+* `POST /approve/{run_id}`: Submit approval inputs to resume paused states.

run_dbt-0.1.0/README.md

@@ -0,0 +1,133 @@
+# PDT (Process Deploy Tool)
+
+> **Git-native runtime for state-bounded operational AI workflows.**
+
+`pdt` is a developer-focused Command Line Interface (CLI) and runtime engine designed to govern, parse, lint, and execute standard-conforming **`PROCESS.md`** files. 
+
+Inspired by analytics engineering tools like `dbt`, `pdt` decouples general-purpose LLM capabilities (**skills**) from operational business logic and policies (**processes**). It provides deterministic execution boundaries, step-by-step state preservation, and human-in-the-loop (HITL) gates.
+
+---
+
+## Core Philosophy: Workflow Engineering
+
+Most operational teams do not need another open-ended autonomous agent. They require a reliable framework to transform recurring, high-stakes business processes into structured, version-controlled workflows. 
+
+PDT establishes this via **Workflow Engineering**—pairing deterministic execution structures with bounded model reasoning:
+* **Decoupled Skills & Processes**: Skills describe *how* to perform a reusable task (general/mechanical); processes describe *what* should happen, in what order, and under what constraints (contextual/governing).
+* **Markdown as Code**: `PROCESS.md` files are the "SQL of operations"—readable by non-developer process owners, versioned in Git, and executable by a computer.
+* **Deterministic Bounding**: Instead of letting an LLM navigate a workflow in an open-ended loop (resulting in unpredictable execution costs and loops), the PDT runtime runs one isolated step at a time, enforcing boundaries and security.
+* **Human-Centered Exceptions**: When exceptions or gates are hit, the runtime halts, saves state, and alerts humans to verify or approve the execution.
+
+---
+
+## Workspace Layout
+
+A conforming PDT workspace is organized as follows:
+
+```text
+/workspace
+├── pdt.yaml                          # Workspace configuration
+├── processes/                        # Executable workflows
+│   └── growth_experiment_review/
+│       └── PROCESS.md
+├── skills/                           # Capability guides
+│   └── experiment-analysis/
+│       └── SKILL.md
+├── tools/                            # Code execution units
+│   └── experiment_lookup/
+│       ├── tool.yaml
+│       └── main.py
+└── schemas/                          # Data validation contracts
+    └── experiment-summary.schema.json
+```
+
+---
+
+## Anatomy of `PROCESS.md`
+
+An executable SOP contains three main components:
+
+```markdown
+---
+id: growth_experiment_review
+name: Growth Experiment Review
+version: 0.1.0
+owner: growth-team
+status: active
+runtime: pdt.process.v0
+---
+# Description
+A workflow to review growth experiments, aggregate conversions, and perform high-level evaluation before approval.
+
+# Workflow
+## Step 1: Load active experiments
+Lookup all active experiments using the tool `tool/experiment_lookup`.
+
+## Step 2: Assess statistical performance
+Evaluate the total conversion metrics using `skill/experiment-analysis` and construct a structured JSON summary matching `schema/experiment-summary`.
+
+## Step 3: Approve experiment
+Review the assessment and request final business approval before closing.
+```
+
+---
+
+## CLI Commands & Usage
+
+Install the PDT package:
+```bash
+pip install run-dbt
+```
+
+### 1. `pdt init`
+Initialize a new standard workspace directory layout with default configuration:
+```bash
+pdt init [workspace_path]
+```
+
+### 2. `pdt lint`
+Validate workspace config, verify step index ordering, and resolve all inline reference links to confirm they point to valid skills, tools, processes, and schemas:
+```bash
+pdt lint processes/growth_experiment_review/PROCESS.md
+```
+
+### 3. `pdt parse`
+Parse a `PROCESS.md` file and output a clean Abstract Syntax Tree (AST) in JSON format:
+```bash
+pdt parse processes/growth_experiment_review/PROCESS.md
+```
+
+### 4. `pdt run`
+Execute the workflow steps sequentially. PDT automatically runs local tools, saves evidence, compiles bounded prompts, and pauses when a human gate (e.g. "approval") is encountered.
+
+* **Execute workflow fully:**
+  ```bash
+  pdt run processes/growth_experiment_review/PROCESS.md --input metrics.json
+  ```
+* **Run a single step only:**
+  ```bash
+  pdt run processes/growth_experiment_review/PROCESS.md --step 2
+  ```
+* **Resume a paused workflow:**
+  ```bash
+  pdt run --resume run_98a72f1c
+  ```
+
+### 5. `pdt deploy`
+Package the workspace and generate container/deployment configurations:
+```bash
+pdt deploy --target docker --dry-run
+```
+
+---
+
+## Webhook Server Daemon
+
+Deploy the workspace as a serverless runtime using the built-in FastAPI daemon:
+```bash
+uvicorn pdt_cli.server:app --port 8080
+```
+This exposes REST API endpoints to trigger and manage workflows remotely:
+* `POST /run/{process_id}`: Trigger step execution with input payload.
+* `GET /status/{run_id}`: Check status and inspect run evidence.
+* `POST /approve/{run_id}`: Submit approval inputs to resume paused states.