instructvault 0.2.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- instructvault-0.2.0/.github/ISSUE_TEMPLATE/bug_report.md +21 -0
- instructvault-0.2.0/.github/ISSUE_TEMPLATE/feature_request.md +13 -0
- instructvault-0.2.0/.github/pull_request_template.md +8 -0
- instructvault-0.2.0/.github/workflows/release.yml +21 -0
- instructvault-0.2.0/CHANGELOG.md +12 -0
- instructvault-0.2.0/CODE_OF_CONDUCT.md +20 -0
- instructvault-0.2.0/CONTRIBUTING.md +18 -0
- instructvault-0.2.0/LICENSE +5 -0
- instructvault-0.2.0/PKG-INFO +192 -0
- instructvault-0.2.0/README.md +169 -0
- instructvault-0.2.0/SECURITY.md +6 -0
- instructvault-0.2.0/VISION_DOC.md +426 -0
- instructvault-0.2.0/docs/ci.md +9 -0
- instructvault-0.2.0/docs/ci_templates/Jenkinsfile +18 -0
- instructvault-0.2.0/docs/ci_templates/gitlab-ci.yml +18 -0
- instructvault-0.2.0/docs/cookbooks.md +135 -0
- instructvault-0.2.0/docs/dropin_guide.md +27 -0
- instructvault-0.2.0/docs/governance.md +10 -0
- instructvault-0.2.0/docs/playground.md +10 -0
- instructvault-0.2.0/docs/release_checklist.md +22 -0
- instructvault-0.2.0/docs/templates/CODEOWNERS +3 -0
- instructvault-0.2.0/examples/datasets/classifier_cases.jsonl +2 -0
- instructvault-0.2.0/examples/datasets/rag_agent_cases.jsonl +2 -0
- instructvault-0.2.0/examples/datasets/rag_answer_cases.jsonl +2 -0
- instructvault-0.2.0/examples/datasets/support_cases.jsonl +2 -0
- instructvault-0.2.0/examples/prompts/classifier.prompt.yml +14 -0
- instructvault-0.2.0/examples/prompts/guardrail.prompt.json +26 -0
- instructvault-0.2.0/examples/prompts/rag_agent.prompt.yml +18 -0
- instructvault-0.2.0/examples/prompts/rag_answer.prompt.yml +21 -0
- instructvault-0.2.0/examples/prompts/support_reply.prompt.yml +17 -0
- instructvault-0.2.0/playground/README.md +21 -0
- instructvault-0.2.0/playground/ivault_playground/__init__.py +1 -0
- instructvault-0.2.0/playground/ivault_playground/app.py +187 -0
- instructvault-0.2.0/playground/pyproject.toml +23 -0
- instructvault-0.2.0/pyproject.toml +52 -0
- instructvault-0.2.0/src/instructvault/__init__.py +2 -0
- instructvault-0.2.0/src/instructvault/bundle.py +62 -0
- instructvault-0.2.0/src/instructvault/cli.py +157 -0
- instructvault-0.2.0/src/instructvault/diff.py +4 -0
- instructvault-0.2.0/src/instructvault/eval.py +53 -0
- instructvault-0.2.0/src/instructvault/io.py +26 -0
- instructvault-0.2.0/src/instructvault/junit.py +30 -0
- instructvault-0.2.0/src/instructvault/render.py +22 -0
- instructvault-0.2.0/src/instructvault/scaffold.py +62 -0
- instructvault-0.2.0/src/instructvault/sdk.py +31 -0
- instructvault-0.2.0/src/instructvault/spec.py +48 -0
- instructvault-0.2.0/src/instructvault/store.py +25 -0
- instructvault-0.2.0/tests/test_cli_basic.py +85 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Bug report
|
|
3
|
+
about: Report a reproducible issue
|
|
4
|
+
title: "[Bug] "
|
|
5
|
+
labels: bug
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Summary
|
|
9
|
+
What happened?
|
|
10
|
+
|
|
11
|
+
## Steps to reproduce
|
|
12
|
+
1.
|
|
13
|
+
2.
|
|
14
|
+
3.
|
|
15
|
+
|
|
16
|
+
## Expected behavior
|
|
17
|
+
|
|
18
|
+
## Environment
|
|
19
|
+
- OS:
|
|
20
|
+
- Python:
|
|
21
|
+
- InstructVault version:
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
name: release
|
|
2
|
+
on:
|
|
3
|
+
push:
|
|
4
|
+
tags:
|
|
5
|
+
- "v*"
|
|
6
|
+
|
|
7
|
+
jobs:
|
|
8
|
+
build-and-publish:
|
|
9
|
+
runs-on: ubuntu-latest
|
|
10
|
+
steps:
|
|
11
|
+
- uses: actions/checkout@v4
|
|
12
|
+
- uses: actions/setup-python@v5
|
|
13
|
+
with:
|
|
14
|
+
python-version: "3.11"
|
|
15
|
+
- run: python -m pip install --upgrade pip
|
|
16
|
+
- run: pip install build twine
|
|
17
|
+
- run: python -m build
|
|
18
|
+
- env:
|
|
19
|
+
TWINE_USERNAME: __token__
|
|
20
|
+
TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }}
|
|
21
|
+
run: python -m twine upload dist/*
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to this project will be documented in this file.
|
|
4
|
+
|
|
5
|
+
## [0.2.0] - 2026-02-01
|
|
6
|
+
### Added
|
|
7
|
+
- Spec versioning (`spec_version`)
|
|
8
|
+
- JSON prompt support
|
|
9
|
+
- Build-time bundling (`ivault bundle`)
|
|
10
|
+
- JSON outputs for CLI commands
|
|
11
|
+
- Cookbooks, drop-in guide, and CI templates
|
|
12
|
+
- Minimal playground scaffold
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Contributor Covenant Code of Conduct
|
|
2
|
+
|
|
3
|
+
## Our Pledge
|
|
4
|
+
We pledge to make participation in our community a harassment-free experience for everyone.
|
|
5
|
+
|
|
6
|
+
## Our Standards
|
|
7
|
+
Examples of behavior that contributes to a positive environment include:
|
|
8
|
+
- Being respectful and considerate
|
|
9
|
+
- Accepting constructive feedback
|
|
10
|
+
- Focusing on what is best for the community
|
|
11
|
+
|
|
12
|
+
Examples of unacceptable behavior include:
|
|
13
|
+
- Harassment or discrimination of any kind
|
|
14
|
+
- Personal attacks or trolling
|
|
15
|
+
|
|
16
|
+
## Enforcement
|
|
17
|
+
For enforcement issues, contact the project maintainers.
|
|
18
|
+
|
|
19
|
+
## Attribution
|
|
20
|
+
This Code of Conduct is adapted from the Contributor Covenant, version 2.1.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Contributing
|
|
2
|
+
|
|
3
|
+
Thanks for contributing to InstructVault.
|
|
4
|
+
|
|
5
|
+
## Development setup
|
|
6
|
+
```
|
|
7
|
+
python -m venv .venv
|
|
8
|
+
source .venv/bin/activate
|
|
9
|
+
pip install -e ".[dev]"
|
|
10
|
+
pytest
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
## Pull requests
|
|
14
|
+
- Keep changes focused and small
|
|
15
|
+
- Add tests for new behavior
|
|
16
|
+
- Run `pytest` locally
|
|
17
|
+
- Update docs if user-facing behavior changes
|
|
18
|
+
|
|
@@ -0,0 +1,192 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: instructvault
|
|
3
|
+
Version: 0.2.0
|
|
4
|
+
Summary: Git-first prompt registry + CI evals + lightweight runtime SDK (ivault).
|
|
5
|
+
Project-URL: Homepage, https://github.com/05satyam/instruct_vault
|
|
6
|
+
Project-URL: Repository, https://github.com/05satyam/instruct_vault
|
|
7
|
+
Author: InstructVault OSS Maintainers
|
|
8
|
+
License: Apache-2.0
|
|
9
|
+
License-File: LICENSE
|
|
10
|
+
Requires-Python: >=3.10
|
|
11
|
+
Requires-Dist: jinja2>=3.1
|
|
12
|
+
Requires-Dist: pydantic>=2.7
|
|
13
|
+
Requires-Dist: pyyaml>=6.0
|
|
14
|
+
Requires-Dist: rich>=13.7
|
|
15
|
+
Requires-Dist: typer>=0.12
|
|
16
|
+
Provides-Extra: dev
|
|
17
|
+
Requires-Dist: mypy>=1.10; extra == 'dev'
|
|
18
|
+
Requires-Dist: pytest-cov>=5.0; extra == 'dev'
|
|
19
|
+
Requires-Dist: pytest>=8.0; extra == 'dev'
|
|
20
|
+
Requires-Dist: ruff>=0.6; extra == 'dev'
|
|
21
|
+
Requires-Dist: types-pyyaml; extra == 'dev'
|
|
22
|
+
Description-Content-Type: text/markdown
|
|
23
|
+
|
|
24
|
+
# InstructVault (`ivault`)
|
|
25
|
+
**Git‑first prompt hub for teams and individual developers.**
|
|
26
|
+
|
|
27
|
+
InstructVault makes prompts **first‑class, governed, testable, versioned artifacts** — just like code — while keeping runtime **fast and local**.
|
|
28
|
+
|
|
29
|
+
## What this does (at a glance)
|
|
30
|
+
- **Prompts live in Git** as YAML/JSON files
|
|
31
|
+
- **CI validates + evaluates** prompts on every change
|
|
32
|
+
- **Releases are tags/SHAs**, reproducible by design
|
|
33
|
+
- **Runtime stays lightweight** (local read or bundle artifact)
|
|
34
|
+
|
|
35
|
+
## System flow (Mermaid)
|
|
36
|
+
```mermaid
|
|
37
|
+
flowchart LR
|
|
38
|
+
A[Prompt files<br/>YAML/JSON] --> B[PR Review]
|
|
39
|
+
B --> C[CI: validate + eval]
|
|
40
|
+
C --> D{Release?}
|
|
41
|
+
D -- tag/SHA --> E[Bundle artifact]
|
|
42
|
+
D -- tag/SHA --> F[Deploy app]
|
|
43
|
+
E --> F
|
|
44
|
+
F --> G[Runtime render<br/>local or bundle]
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Why this exists
|
|
48
|
+
Enterprises already have Git + PR reviews + CI/CD. Prompts usually don’t.
|
|
49
|
+
InstructVault brings **prompt‑as‑code** without requiring a server, database, or platform.
|
|
50
|
+
|
|
51
|
+
## Features
|
|
52
|
+
- ✅ Git‑native versioning (tags/SHAs = releases)
|
|
53
|
+
- ✅ CLI‑first (`init`, `validate`, `render`, `eval`, `diff`, `resolve`, `bundle`)
|
|
54
|
+
- ✅ LLM‑framework agnostic (returns standard `{role, content}` messages)
|
|
55
|
+
- ✅ CI‑friendly reports (JSON + optional JUnit XML)
|
|
56
|
+
- ✅ No runtime latency tax (local read or bundle)
|
|
57
|
+
- ✅ Optional playground (separate package)
|
|
58
|
+
|
|
59
|
+
## Install
|
|
60
|
+
### Users
|
|
61
|
+
```bash
|
|
62
|
+
pip install instructvault
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### Contributors
|
|
66
|
+
```bash
|
|
67
|
+
git clone <your-repo>
|
|
68
|
+
cd instructvault
|
|
69
|
+
python -m venv .venv
|
|
70
|
+
source .venv/bin/activate
|
|
71
|
+
pip install -e ".[dev]"
|
|
72
|
+
pytest
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Quickstart (end‑to‑end)
|
|
76
|
+
|
|
77
|
+
### 1) Initialize a repo
|
|
78
|
+
```bash
|
|
79
|
+
ivault init
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### 2) Create a prompt
|
|
83
|
+
`prompts/support_reply.prompt.yml` (YAML or JSON)
|
|
84
|
+
```yaml
|
|
85
|
+
spec_version: "1.0"
|
|
86
|
+
name: support_reply
|
|
87
|
+
description: Respond to a support ticket with empathy and clear steps.
|
|
88
|
+
model_defaults:
|
|
89
|
+
temperature: 0.2
|
|
90
|
+
|
|
91
|
+
variables:
|
|
92
|
+
required: [ticket_text]
|
|
93
|
+
optional: [customer_name]
|
|
94
|
+
|
|
95
|
+
messages:
|
|
96
|
+
- role: system
|
|
97
|
+
content: |
|
|
98
|
+
You are a support engineer. Be concise, empathetic, and action-oriented.
|
|
99
|
+
- role: user
|
|
100
|
+
content: |
|
|
101
|
+
Customer: {{ customer_name | default("there") }}
|
|
102
|
+
Ticket:
|
|
103
|
+
{{ ticket_text }}
|
|
104
|
+
|
|
105
|
+
tests:
|
|
106
|
+
- name: must_contain_customer_and_ticket
|
|
107
|
+
vars:
|
|
108
|
+
ticket_text: "My order arrived damaged."
|
|
109
|
+
customer_name: "Alex"
|
|
110
|
+
assert:
|
|
111
|
+
contains_all: ["Customer:", "Ticket:"]
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### 3) Validate + render locally
|
|
115
|
+
```bash
|
|
116
|
+
ivault validate prompts
|
|
117
|
+
ivault render prompts/support_reply.prompt.yml --vars '{"ticket_text":"My app crashed.","customer_name":"Sam"}'
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
### 4) Add dataset‑driven eval
|
|
121
|
+
`datasets/support_cases.jsonl`
|
|
122
|
+
```jsonl
|
|
123
|
+
{"vars":{"ticket_text":"Order arrived damaged","customer_name":"Alex"},"assert":{"contains_any":["Ticket:"]}}
|
|
124
|
+
{"vars":{"ticket_text":"Need refund"},"assert":{"contains_all":["Ticket:"]}}
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
```bash
|
|
128
|
+
ivault eval prompts/support_reply.prompt.yml --dataset datasets/support_cases.jsonl --report out/report.json --junit out/junit.xml
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
### 5) Version prompts with tags
|
|
132
|
+
```bash
|
|
133
|
+
git add prompts datasets
|
|
134
|
+
git commit -m "Add support prompts + eval dataset"
|
|
135
|
+
git tag prompts/v1.0.0
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
### 6) Load by Git ref at runtime
|
|
139
|
+
```python
|
|
140
|
+
from instructvault import InstructVault
|
|
141
|
+
|
|
142
|
+
vault = InstructVault(repo_root=".")
|
|
143
|
+
msgs = vault.render(
|
|
144
|
+
"prompts/support_reply.prompt.yml",
|
|
145
|
+
vars={"ticket_text":"My order is delayed", "customer_name":"Ava"},
|
|
146
|
+
ref="prompts/v1.0.0",
|
|
147
|
+
)
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
### 7) Bundle prompts at build time (optional)
|
|
151
|
+
```bash
|
|
152
|
+
ivault bundle --prompts prompts --out out/ivault.bundle.json --ref prompts/v1.0.0
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
```python
|
|
156
|
+
from instructvault import InstructVault
|
|
157
|
+
vault = InstructVault(bundle_path="out/ivault.bundle.json")
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
## How teams use this in production
|
|
161
|
+
1) Prompt changes go through PRs
|
|
162
|
+
2) CI runs `validate` + `eval`
|
|
163
|
+
3) Tags or bundles become the deployable artifact
|
|
164
|
+
4) Apps load by tag or bundle (no runtime network calls)
|
|
165
|
+
|
|
166
|
+
## Datasets (why JSONL)
|
|
167
|
+
Datasets are **deterministic eval inputs** checked into Git. This makes CI reproducible and audit‑friendly.
|
|
168
|
+
For cloud datasets, use a CI pre‑step (e.g., download from S3) and then run `ivault eval` on the local file.
|
|
169
|
+
|
|
170
|
+
## Playground (optional)
|
|
171
|
+
A minimal playground exists under `playground/` for local or org‑hosted use.
|
|
172
|
+
It lists prompts, renders with variables, and runs evals — without touching production prompts directly.
|
|
173
|
+
For local dev, run from the repo root:
|
|
174
|
+
```bash
|
|
175
|
+
export IVAULT_REPO_ROOT=/path/to/your/repo
|
|
176
|
+
PYTHONPATH=. uvicorn ivault_playground.app:app --reload
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
## Docs
|
|
180
|
+
- `docs/governance.md`
|
|
181
|
+
- `docs/ci.md`
|
|
182
|
+
- `docs/playground.md`
|
|
183
|
+
- `docs/cookbooks.md`
|
|
184
|
+
- `docs/dropin_guide.md`
|
|
185
|
+
- `docs/release_checklist.md`
|
|
186
|
+
- `docs/ci_templates/gitlab-ci.yml`
|
|
187
|
+
- `docs/ci_templates/Jenkinsfile`
|
|
188
|
+
- `CHANGELOG.md`
|
|
189
|
+
- `CODE_OF_CONDUCT.md`
|
|
190
|
+
|
|
191
|
+
## License
|
|
192
|
+
Apache‑2.0
|
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
# InstructVault (`ivault`)
|
|
2
|
+
**Git‑first prompt hub for teams and individual developers.**
|
|
3
|
+
|
|
4
|
+
InstructVault makes prompts **first‑class, governed, testable, versioned artifacts** — just like code — while keeping runtime **fast and local**.
|
|
5
|
+
|
|
6
|
+
## What this does (at a glance)
|
|
7
|
+
- **Prompts live in Git** as YAML/JSON files
|
|
8
|
+
- **CI validates + evaluates** prompts on every change
|
|
9
|
+
- **Releases are tags/SHAs**, reproducible by design
|
|
10
|
+
- **Runtime stays lightweight** (local read or bundle artifact)
|
|
11
|
+
|
|
12
|
+
## System flow (Mermaid)
|
|
13
|
+
```mermaid
|
|
14
|
+
flowchart LR
|
|
15
|
+
A[Prompt files<br/>YAML/JSON] --> B[PR Review]
|
|
16
|
+
B --> C[CI: validate + eval]
|
|
17
|
+
C --> D{Release?}
|
|
18
|
+
D -- tag/SHA --> E[Bundle artifact]
|
|
19
|
+
D -- tag/SHA --> F[Deploy app]
|
|
20
|
+
E --> F
|
|
21
|
+
F --> G[Runtime render<br/>local or bundle]
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Why this exists
|
|
25
|
+
Enterprises already have Git + PR reviews + CI/CD. Prompts usually don’t.
|
|
26
|
+
InstructVault brings **prompt‑as‑code** without requiring a server, database, or platform.
|
|
27
|
+
|
|
28
|
+
## Features
|
|
29
|
+
- ✅ Git‑native versioning (tags/SHAs = releases)
|
|
30
|
+
- ✅ CLI‑first (`init`, `validate`, `render`, `eval`, `diff`, `resolve`, `bundle`)
|
|
31
|
+
- ✅ LLM‑framework agnostic (returns standard `{role, content}` messages)
|
|
32
|
+
- ✅ CI‑friendly reports (JSON + optional JUnit XML)
|
|
33
|
+
- ✅ No runtime latency tax (local read or bundle)
|
|
34
|
+
- ✅ Optional playground (separate package)
|
|
35
|
+
|
|
36
|
+
## Install
|
|
37
|
+
### Users
|
|
38
|
+
```bash
|
|
39
|
+
pip install instructvault
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### Contributors
|
|
43
|
+
```bash
|
|
44
|
+
git clone <your-repo>
|
|
45
|
+
cd instructvault
|
|
46
|
+
python -m venv .venv
|
|
47
|
+
source .venv/bin/activate
|
|
48
|
+
pip install -e ".[dev]"
|
|
49
|
+
pytest
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Quickstart (end‑to‑end)
|
|
53
|
+
|
|
54
|
+
### 1) Initialize a repo
|
|
55
|
+
```bash
|
|
56
|
+
ivault init
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### 2) Create a prompt
|
|
60
|
+
`prompts/support_reply.prompt.yml` (YAML or JSON)
|
|
61
|
+
```yaml
|
|
62
|
+
spec_version: "1.0"
|
|
63
|
+
name: support_reply
|
|
64
|
+
description: Respond to a support ticket with empathy and clear steps.
|
|
65
|
+
model_defaults:
|
|
66
|
+
temperature: 0.2
|
|
67
|
+
|
|
68
|
+
variables:
|
|
69
|
+
required: [ticket_text]
|
|
70
|
+
optional: [customer_name]
|
|
71
|
+
|
|
72
|
+
messages:
|
|
73
|
+
- role: system
|
|
74
|
+
content: |
|
|
75
|
+
You are a support engineer. Be concise, empathetic, and action-oriented.
|
|
76
|
+
- role: user
|
|
77
|
+
content: |
|
|
78
|
+
Customer: {{ customer_name | default("there") }}
|
|
79
|
+
Ticket:
|
|
80
|
+
{{ ticket_text }}
|
|
81
|
+
|
|
82
|
+
tests:
|
|
83
|
+
- name: must_contain_customer_and_ticket
|
|
84
|
+
vars:
|
|
85
|
+
ticket_text: "My order arrived damaged."
|
|
86
|
+
customer_name: "Alex"
|
|
87
|
+
assert:
|
|
88
|
+
contains_all: ["Customer:", "Ticket:"]
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
### 3) Validate + render locally
|
|
92
|
+
```bash
|
|
93
|
+
ivault validate prompts
|
|
94
|
+
ivault render prompts/support_reply.prompt.yml --vars '{"ticket_text":"My app crashed.","customer_name":"Sam"}'
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### 4) Add dataset‑driven eval
|
|
98
|
+
`datasets/support_cases.jsonl`
|
|
99
|
+
```jsonl
|
|
100
|
+
{"vars":{"ticket_text":"Order arrived damaged","customer_name":"Alex"},"assert":{"contains_any":["Ticket:"]}}
|
|
101
|
+
{"vars":{"ticket_text":"Need refund"},"assert":{"contains_all":["Ticket:"]}}
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
```bash
|
|
105
|
+
ivault eval prompts/support_reply.prompt.yml --dataset datasets/support_cases.jsonl --report out/report.json --junit out/junit.xml
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
### 5) Version prompts with tags
|
|
109
|
+
```bash
|
|
110
|
+
git add prompts datasets
|
|
111
|
+
git commit -m "Add support prompts + eval dataset"
|
|
112
|
+
git tag prompts/v1.0.0
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### 6) Load by Git ref at runtime
|
|
116
|
+
```python
|
|
117
|
+
from instructvault import InstructVault
|
|
118
|
+
|
|
119
|
+
vault = InstructVault(repo_root=".")
|
|
120
|
+
msgs = vault.render(
|
|
121
|
+
"prompts/support_reply.prompt.yml",
|
|
122
|
+
vars={"ticket_text":"My order is delayed", "customer_name":"Ava"},
|
|
123
|
+
ref="prompts/v1.0.0",
|
|
124
|
+
)
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
### 7) Bundle prompts at build time (optional)
|
|
128
|
+
```bash
|
|
129
|
+
ivault bundle --prompts prompts --out out/ivault.bundle.json --ref prompts/v1.0.0
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
```python
|
|
133
|
+
from instructvault import InstructVault
|
|
134
|
+
vault = InstructVault(bundle_path="out/ivault.bundle.json")
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
## How teams use this in production
|
|
138
|
+
1) Prompt changes go through PRs
|
|
139
|
+
2) CI runs `validate` + `eval`
|
|
140
|
+
3) Tags or bundles become the deployable artifact
|
|
141
|
+
4) Apps load by tag or bundle (no runtime network calls)
|
|
142
|
+
|
|
143
|
+
## Datasets (why JSONL)
|
|
144
|
+
Datasets are **deterministic eval inputs** checked into Git. This makes CI reproducible and audit‑friendly.
|
|
145
|
+
For cloud datasets, use a CI pre‑step (e.g., download from S3) and then run `ivault eval` on the local file.
|
|
146
|
+
|
|
147
|
+
## Playground (optional)
|
|
148
|
+
A minimal playground exists under `playground/` for local or org‑hosted use.
|
|
149
|
+
It lists prompts, renders with variables, and runs evals — without touching production prompts directly.
|
|
150
|
+
For local dev, run from the repo root:
|
|
151
|
+
```bash
|
|
152
|
+
export IVAULT_REPO_ROOT=/path/to/your/repo
|
|
153
|
+
PYTHONPATH=. uvicorn ivault_playground.app:app --reload
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
## Docs
|
|
157
|
+
- `docs/governance.md`
|
|
158
|
+
- `docs/ci.md`
|
|
159
|
+
- `docs/playground.md`
|
|
160
|
+
- `docs/cookbooks.md`
|
|
161
|
+
- `docs/dropin_guide.md`
|
|
162
|
+
- `docs/release_checklist.md`
|
|
163
|
+
- `docs/ci_templates/gitlab-ci.yml`
|
|
164
|
+
- `docs/ci_templates/Jenkinsfile`
|
|
165
|
+
- `CHANGELOG.md`
|
|
166
|
+
- `CODE_OF_CONDUCT.md`
|
|
167
|
+
|
|
168
|
+
## License
|
|
169
|
+
Apache‑2.0
|