readiness-as-code 0.7.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.
- readiness_as_code-0.7.0/LICENSE +21 -0
- readiness_as_code-0.7.0/PKG-INFO +272 -0
- readiness_as_code-0.7.0/README.md +245 -0
- readiness_as_code-0.7.0/pyproject.toml +61 -0
- readiness_as_code-0.7.0/readiness_as_code.egg-info/PKG-INFO +272 -0
- readiness_as_code-0.7.0/readiness_as_code.egg-info/SOURCES.txt +47 -0
- readiness_as_code-0.7.0/readiness_as_code.egg-info/dependency_links.txt +1 -0
- readiness_as_code-0.7.0/readiness_as_code.egg-info/entry_points.txt +3 -0
- readiness_as_code-0.7.0/readiness_as_code.egg-info/requires.txt +3 -0
- readiness_as_code-0.7.0/readiness_as_code.egg-info/top_level.txt +1 -0
- readiness_as_code-0.7.0/ready/__init__.py +0 -0
- readiness_as_code-0.7.0/ready/__main__.py +4 -0
- readiness_as_code-0.7.0/ready/adapters/__init__.py +61 -0
- readiness_as_code-0.7.0/ready/adapters/ado.py +174 -0
- readiness_as_code-0.7.0/ready/adapters/github_issues.py +154 -0
- readiness_as_code-0.7.0/ready/adapters/jira.py +283 -0
- readiness_as_code-0.7.0/ready/engine.py +460 -0
- readiness_as_code-0.7.0/ready/examples/engineering-review/checkpoint-definitions.json +522 -0
- readiness_as_code-0.7.0/ready/examples/governance/checkpoint-definitions.json +303 -0
- readiness_as_code-0.7.0/ready/examples/operational-review/checkpoint-definitions.json +273 -0
- readiness_as_code-0.7.0/ready/examples/security-baseline/checkpoint-definitions.json +177 -0
- readiness_as_code-0.7.0/ready/examples/service-migration/checkpoint-definitions.json +148 -0
- readiness_as_code-0.7.0/ready/examples/starter-pack/checkpoint-definitions.json +220 -0
- readiness_as_code-0.7.0/ready/examples/starter-pack/exceptions.json +4 -0
- readiness_as_code-0.7.0/ready/examples/starter-pack/external-evidence.json +4 -0
- readiness_as_code-0.7.0/ready/examples/telemetry/checkpoint-definitions.json +157 -0
- readiness_as_code-0.7.0/ready/examples/web-api/README.md +45 -0
- readiness_as_code-0.7.0/ready/examples/web-api/checkpoint-definitions.json +305 -0
- readiness_as_code-0.7.0/ready/formatters/__init__.py +6 -0
- readiness_as_code-0.7.0/ready/formatters/json_formatter.py +10 -0
- readiness_as_code-0.7.0/ready/formatters/markdown.py +175 -0
- readiness_as_code-0.7.0/ready/formatters/terminal.py +216 -0
- readiness_as_code-0.7.0/ready/mcp_server.py +318 -0
- readiness_as_code-0.7.0/ready/plugins/__init__.py +7 -0
- readiness_as_code-0.7.0/ready/plugins/base.py +60 -0
- readiness_as_code-0.7.0/ready/plugins/external_plugin.py +41 -0
- readiness_as_code-0.7.0/ready/plugins/file_count_plugin.py +15 -0
- readiness_as_code-0.7.0/ready/plugins/file_exists_plugin.py +19 -0
- readiness_as_code-0.7.0/ready/plugins/glob_plugin.py +45 -0
- readiness_as_code-0.7.0/ready/plugins/grep_plugin.py +62 -0
- readiness_as_code-0.7.0/ready/plugins/hybrid_plugin.py +68 -0
- readiness_as_code-0.7.0/ready/plugins/json_path_plugin.py +52 -0
- readiness_as_code-0.7.0/ready/plugins/registry.py +61 -0
- readiness_as_code-0.7.0/ready/plugins/utils.py +91 -0
- readiness_as_code-0.7.0/ready/ready.py +2717 -0
- readiness_as_code-0.7.0/ready/validators.py +52 -0
- readiness_as_code-0.7.0/ready/watch.py +256 -0
- readiness_as_code-0.7.0/setup.cfg +4 -0
- readiness_as_code-0.7.0/tests/test_validators.py +958 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Jeremiah Walters
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,272 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: readiness-as-code
|
|
3
|
+
Version: 0.7.0
|
|
4
|
+
Summary: Know before you ship — continuous readiness as a folder in your repo.
|
|
5
|
+
Author: Jeremiah Walters
|
|
6
|
+
License: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/jtwalters25/readiness-as-code
|
|
8
|
+
Project-URL: Documentation, https://github.com/jtwalters25/readiness-as-code/tree/main/docs
|
|
9
|
+
Project-URL: Repository, https://github.com/jtwalters25/readiness-as-code
|
|
10
|
+
Project-URL: Issues, https://github.com/jtwalters25/readiness-as-code/issues
|
|
11
|
+
Keywords: compliance,code-review,quality-gates,operational-readiness,devops,ci-cd,policy-as-code
|
|
12
|
+
Classifier: Development Status :: 3 - Alpha
|
|
13
|
+
Classifier: Intended Audience :: Developers
|
|
14
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
15
|
+
Classifier: Programming Language :: Python :: 3
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
17
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
19
|
+
Classifier: Topic :: Software Development :: Quality Assurance
|
|
20
|
+
Classifier: Topic :: Software Development :: Testing
|
|
21
|
+
Requires-Python: >=3.10
|
|
22
|
+
Description-Content-Type: text/markdown
|
|
23
|
+
License-File: LICENSE
|
|
24
|
+
Provides-Extra: mcp
|
|
25
|
+
Requires-Dist: mcp>=1.0; extra == "mcp"
|
|
26
|
+
Dynamic: license-file
|
|
27
|
+
|
|
28
|
+
<p align="center">
|
|
29
|
+
<img src="docs/assets/banner.svg" alt="ready" width="600" />
|
|
30
|
+
</p>
|
|
31
|
+
|
|
32
|
+
<h3 align="center">
|
|
33
|
+
AI tools made your team faster. They didn't make your team safer.
|
|
34
|
+
</h3>
|
|
35
|
+
|
|
36
|
+
<p align="center">
|
|
37
|
+
<strong>ready</strong> is the discipline layer that keeps pace with AI velocity —<br/>
|
|
38
|
+
review criteria as committed definitions, evaluated on every change,<br/>
|
|
39
|
+
with drift detected automatically before it becomes an incident.
|
|
40
|
+
</p>
|
|
41
|
+
|
|
42
|
+
<p align="center">
|
|
43
|
+
No infrastructure. No SaaS. No subscription.<br/>
|
|
44
|
+
JSON definitions + Python scanner + CI template.
|
|
45
|
+
</p>
|
|
46
|
+
|
|
47
|
+
<p align="center">
|
|
48
|
+
<a href="#quickstart">Quickstart</a> •
|
|
49
|
+
<a href="docs/getting-started.md">Docs</a> •
|
|
50
|
+
<a href="docs/architecture-and-tradeoffs.md">Architecture</a> •
|
|
51
|
+
<a href="docs/verification-types.md">Verification Types</a> •
|
|
52
|
+
<a href="docs/ci-integration.md">CI Integration</a>
|
|
53
|
+
</p>
|
|
54
|
+
|
|
55
|
+
<p align="center">
|
|
56
|
+
<a href=".readiness/review-baseline.json">
|
|
57
|
+
<img src="https://img.shields.io/badge/ready-100%25-brightgreen" alt="ready: 100%" />
|
|
58
|
+
</a>
|
|
59
|
+
<img src="https://img.shields.io/badge/license-MIT-blue" alt="MIT License" />
|
|
60
|
+
</p>
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## Connect with Jeremiah Walters
|
|
65
|
+
|
|
66
|
+
[](https://www.linkedin.com/in/jeremiahwalters)
|
|
67
|
+
[](https://x.com/Afrotechnician)
|
|
68
|
+
|
|
69
|
+
## The Problem: Velocity Outran Discipline
|
|
70
|
+
|
|
71
|
+
AI coding tools removed the friction from writing and shipping code. They did not remove the friction from the discipline work — health checks, secrets hygiene, on-call registration, telemetry coverage, auth on every endpoint. Velocity is now AI-speed. Discipline is still person-speed. The gap between the two is where incidents live.
|
|
72
|
+
|
|
73
|
+
Production breakdowns keep hitting strong engineering orgs — not because they lack talent, but because velocity outran the scaffolding. Smart teams moved fast, skipped the prep work, and found out later that the checks weren't there. `ready` is the tool that implements this practice. It replaces **prep work**, not judgment.
|
|
74
|
+
|
|
75
|
+
## Before / After
|
|
76
|
+
|
|
77
|
+
| Before | After |
|
|
78
|
+
|--------|-------|
|
|
79
|
+
| AI writes code in seconds; readiness checks take hours | Readiness checks run in the same pipeline, same pace |
|
|
80
|
+
| Manual checklists that can't keep up with AI velocity | Automated scan on every PR — no human bottleneck |
|
|
81
|
+
| Point-in-time review ceremonies | Continuous compliance, not a quarterly ritual |
|
|
82
|
+
| Drift detected by incidents | Drift detected before merge |
|
|
83
|
+
| Tribal knowledge of what's missing | Structured gap list with file-path evidence |
|
|
84
|
+
| "Are we ready?" is a subjective question | "Are we ready?" has a deterministic answer |
|
|
85
|
+
| Accepted risks forgotten over time | Accepted risks expire and re-surface automatically |
|
|
86
|
+
|
|
87
|
+
## Quickstart
|
|
88
|
+
|
|
89
|
+
```bash
|
|
90
|
+
pip install readiness-as-code
|
|
91
|
+
|
|
92
|
+
cd your-repo
|
|
93
|
+
ready scan
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
> **Windows / PATH issues?** Use `python -m ready scan` — works anywhere Python is installed.
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
ready? — your-service 80% 1 blocking · 2 warnings
|
|
100
|
+
|
|
101
|
+
✗ No secrets in code
|
|
102
|
+
src/config.py:14
|
|
103
|
+
→ Remove hardcoded keys. Use environment variables or a secrets manager.
|
|
104
|
+
|
|
105
|
+
+ 2 warnings (ready scan --verbose)
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
**No config. No accounts. No init required.** `ready scan` auto-detects your project type and runs immediately. When you're ready to customize, run `ready init`.
|
|
109
|
+
|
|
110
|
+
When everything is passing:
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
ready? — your-service 100% ✓ ▲ +12%
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
One line. The drift indicator appears automatically whenever a committed baseline exists.
|
|
117
|
+
|
|
118
|
+
## Origin
|
|
119
|
+
|
|
120
|
+
Built from production use managing 86+ readiness checkpoints across enterprise reliability engineering at scale. This is the vendor-neutral, portable version of a system that enforces production readiness across real services handling real incidents — not a weekend experiment.
|
|
121
|
+
|
|
122
|
+
## How It Works
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
your-repo/
|
|
126
|
+
└── .readiness/
|
|
127
|
+
├── checkpoint-definitions.json # What to check
|
|
128
|
+
├── exceptions.json # Accepted risks + expiry
|
|
129
|
+
├── external-evidence.json # Human attestations for non-code artifacts
|
|
130
|
+
└── review-baseline.json # Last scan snapshot (committed = audit trail)
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
Four JSON files and a scanner. Checkpoints resolve through three verification types: **code checks** (grep/glob/file_exists against the repo), **external checks** (human attestations for artifacts outside the repo), and **hybrid checks** (both must pass). → [Architecture details](docs/architecture-and-tradeoffs.md) · [Verification types](docs/verification-types.md)
|
|
134
|
+
|
|
135
|
+
## Checkpoint Packs
|
|
136
|
+
|
|
137
|
+
Start with a curated pack, then customize:
|
|
138
|
+
|
|
139
|
+
```bash
|
|
140
|
+
ready init # Universal starter (default)
|
|
141
|
+
ready init --pack web-api # REST/HTTP API checks
|
|
142
|
+
ready init --pack security-baseline # Secrets, dependency hygiene, security policy
|
|
143
|
+
ready init --pack telemetry # Logging, tracing, metrics, dashboards
|
|
144
|
+
ready init --pack engineering-review # Full engineering review (arch, security, testing, AI/RAI)
|
|
145
|
+
ready init --pack operational-review # Operational readiness (SLOs, on-call, data, capacity)
|
|
146
|
+
ready init --pack governance # SDLC gates + external review attestations
|
|
147
|
+
ready init --pack service-migration # Service identity migration, auth provisioning, cutover
|
|
148
|
+
ready init --list-packs # Show all available packs
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
| Pack | Checks | Best for |
|
|
152
|
+
|------|--------|----------|
|
|
153
|
+
| `starter` | 11 | Any repo |
|
|
154
|
+
| `web-api` | 17 | REST/HTTP services |
|
|
155
|
+
| `security-baseline` | 8 | Any repo with sensitive data |
|
|
156
|
+
| `telemetry` | 8 | Production services |
|
|
157
|
+
| `engineering-review` | 26 | Pre-launch engineering review |
|
|
158
|
+
| `operational-review` | 14 | Pre-launch operational review |
|
|
159
|
+
| `governance` | 15 | SDLC compliance + sign-off tracking |
|
|
160
|
+
| `service-migration` | 9 | Service identity migration + cutover |
|
|
161
|
+
|
|
162
|
+
## Proven in Production
|
|
163
|
+
|
|
164
|
+
ready is based on a system used in enterprise reliability engineering environments,
|
|
165
|
+
enforcing 80+ readiness checkpoints across real services.
|
|
166
|
+
|
|
167
|
+
It has been used to:
|
|
168
|
+
- continuously evaluate production readiness across services
|
|
169
|
+
- detect regression before deployment
|
|
170
|
+
- reduce reliance on manual review preparation
|
|
171
|
+
|
|
172
|
+
This open-source version is the portable, vendor-neutral implementation.
|
|
173
|
+
|
|
174
|
+
## Key Capabilities
|
|
175
|
+
|
|
176
|
+
- **Auto-drift detection.** If a committed baseline exists, every scan shows a delta: `▲ +12%` or `▼ -5%`. No flags, no extra commands.
|
|
177
|
+
- **Closed-loop work item tracking.** Gaps become tracked work items (GitHub, Azure DevOps, Jira); ticket-closed-but-code-failing flags as **regression**, code-fixed-but-ticket-open as **stale**.
|
|
178
|
+
- **Cross-repo aggregation.** `ready aggregate` turns multiple baselines into an HTML heatmap — *"telemetry gaps in 4 of 5 services"* is a platform problem, not a team problem.
|
|
179
|
+
- **Expiring accepted risks.** Acknowledge a gap with a justification and expiry date; the scanner re-flags it when the expiry passes.
|
|
180
|
+
- **Readiness audit.** `ready audit` reports the health of the readiness system itself — exception age, definition staleness, review_by coverage, score trend.
|
|
181
|
+
- **Codebase-aware inference.** `ready infer` analyzes stack, frameworks, dependencies, ADRs, and auth patterns to propose tailored checkpoints you approve one at a time.
|
|
182
|
+
- **AI-assisted authoring.** `ready author --from guidelines.md` generates a paste-ready prompt for any model (Claude, ChatGPT, Copilot, Cursor, Gemini).
|
|
183
|
+
- **README badge.** `ready badge` generates a shields.io badge from the committed score.
|
|
184
|
+
- **CI gating.** Non-zero exit on red failures; templates for GitHub Actions, Azure Pipelines, GitLab CI. → [Details](docs/ci-integration.md)
|
|
185
|
+
- **Azure DevOps extension.** Pipeline task publishes each checkpoint as a test case, plus a dashboard widget for score, trend, and blocking count. → [Details](ado-extension/README.md)
|
|
186
|
+
|
|
187
|
+
## What This Is Not
|
|
188
|
+
|
|
189
|
+
- **Not a static analysis tool.** SonarQube checks code quality. This checks whether your service meets its review requirements.
|
|
190
|
+
- **Not a policy engine.** OPA/Sentinel enforce infra policies at deploy time. This tracks operational and engineering readiness across code and non-code artifacts.
|
|
191
|
+
- **Not a compliance SaaS.** Drata/RegScale automate regulatory frameworks. This enforces your team's own internal review standards.
|
|
192
|
+
- **Not a replacement for AI coding tools.** It's the complement to them — the discipline layer that keeps pace with the velocity they enable.
|
|
193
|
+
- **Not a replacement for review meetings.** This replaces the prep work so the meeting can focus on judgment calls the scanner can't make.
|
|
194
|
+
|
|
195
|
+
## Commands
|
|
196
|
+
|
|
197
|
+
```bash
|
|
198
|
+
# Scanning
|
|
199
|
+
ready scan # Score + blocking items
|
|
200
|
+
ready scan --verbose # Full detail — all checks, evidence, fix hints
|
|
201
|
+
ready scan --calibrate # Report-only (no exit code failure)
|
|
202
|
+
ready scan --json # Machine-readable output
|
|
203
|
+
ready scan --baseline FILE # Write baseline snapshot (enables drift tracking)
|
|
204
|
+
ready scan --suggest-tuning # Show pattern tuning suggestions after scan
|
|
205
|
+
|
|
206
|
+
# Setup
|
|
207
|
+
ready init # Scaffold .readiness/ with starter pack
|
|
208
|
+
ready init --pack web-api # Scaffold with a specific pack
|
|
209
|
+
ready init --list-packs # List available packs
|
|
210
|
+
|
|
211
|
+
# Authoring & inference
|
|
212
|
+
ready infer # Analyze codebase → propose tailored checkpoints (human approves each)
|
|
213
|
+
ready author --from FILE # Generate AI prompt from a guideline document
|
|
214
|
+
|
|
215
|
+
# Audit trail
|
|
216
|
+
ready badge # Generate README badge from current score
|
|
217
|
+
ready decisions # Show all active, expiring, and expired exceptions
|
|
218
|
+
ready history [BASELINES...] # Show readiness trend from baseline snapshots
|
|
219
|
+
ready audit # Audit exception health, definition staleness, and score health
|
|
220
|
+
|
|
221
|
+
# Work items
|
|
222
|
+
ready items --create # Propose + create work items (human approves each)
|
|
223
|
+
ready items --verify # Cross-check work items vs code
|
|
224
|
+
|
|
225
|
+
# Cross-repo
|
|
226
|
+
ready aggregate PATHS... # Cross-repo heatmap from multiple baselines
|
|
227
|
+
ready aggregate PATHS... --html # Generate self-contained HTML heatmap report
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
## AI Integration
|
|
231
|
+
|
|
232
|
+
ready ships a [Model Context Protocol](https://modelcontextprotocol.io) server (`ready-mcp`) so any MCP client — Claude, Cursor, Copilot — can run scans and inspect checkpoints directly.
|
|
233
|
+
|
|
234
|
+
```bash
|
|
235
|
+
pip install "readiness-as-code[mcp]"
|
|
236
|
+
ready-mcp
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
| Tool | Description |
|
|
240
|
+
|------|-------------|
|
|
241
|
+
| `scan_repo` | Full readiness scan with results |
|
|
242
|
+
| `list_checkpoints` | View all checkpoint definitions |
|
|
243
|
+
| `explain_checkpoint` | Deep-dive on a specific check |
|
|
244
|
+
| `aggregate_baselines` | Cross-repo heatmap for systemic gap detection |
|
|
245
|
+
|
|
246
|
+
For prompt-based authoring with any model:
|
|
247
|
+
|
|
248
|
+
```bash
|
|
249
|
+
ready author --from docs/ops-review.md # generates author-prompt.md, paste into any AI
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
**→ [MCP setup for Claude Desktop, Cursor, VS Code](mcp/README.md)**
|
|
253
|
+
|
|
254
|
+
## Design Principles
|
|
255
|
+
|
|
256
|
+
These principles define what *readiness as code* means in practice. They are not implementation choices — they are the practice itself.
|
|
257
|
+
|
|
258
|
+
1. **Detection, not decisions.** The scanner finds gaps. Humans decide what to do.
|
|
259
|
+
2. **Continuous, not ceremonial.** Checked on every PR, not once a quarter.
|
|
260
|
+
3. **Velocity-aware, not velocity-hostile.** Designed to run at the speed of AI-assisted development — no human bottleneck in the loop.
|
|
261
|
+
4. **Portable, not hosted.** Files in your repo. No infrastructure.
|
|
262
|
+
5. **Evidence-backed, not trust-based.** Every assertion has a file path, attestation, or work item.
|
|
263
|
+
6. **Expiring, not permanent.** Accepted risks have expiry dates. Nothing is forever.
|
|
264
|
+
7. **Score-first, not report-first.** The answer to "are we ready?" is one line. Detail is on demand.
|
|
265
|
+
|
|
266
|
+
## Contributing
|
|
267
|
+
|
|
268
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
269
|
+
|
|
270
|
+
## License
|
|
271
|
+
|
|
272
|
+
[MIT](LICENSE)
|
|
@@ -0,0 +1,245 @@
|
|
|
1
|
+
<p align="center">
|
|
2
|
+
<img src="docs/assets/banner.svg" alt="ready" width="600" />
|
|
3
|
+
</p>
|
|
4
|
+
|
|
5
|
+
<h3 align="center">
|
|
6
|
+
AI tools made your team faster. They didn't make your team safer.
|
|
7
|
+
</h3>
|
|
8
|
+
|
|
9
|
+
<p align="center">
|
|
10
|
+
<strong>ready</strong> is the discipline layer that keeps pace with AI velocity —<br/>
|
|
11
|
+
review criteria as committed definitions, evaluated on every change,<br/>
|
|
12
|
+
with drift detected automatically before it becomes an incident.
|
|
13
|
+
</p>
|
|
14
|
+
|
|
15
|
+
<p align="center">
|
|
16
|
+
No infrastructure. No SaaS. No subscription.<br/>
|
|
17
|
+
JSON definitions + Python scanner + CI template.
|
|
18
|
+
</p>
|
|
19
|
+
|
|
20
|
+
<p align="center">
|
|
21
|
+
<a href="#quickstart">Quickstart</a> •
|
|
22
|
+
<a href="docs/getting-started.md">Docs</a> •
|
|
23
|
+
<a href="docs/architecture-and-tradeoffs.md">Architecture</a> •
|
|
24
|
+
<a href="docs/verification-types.md">Verification Types</a> •
|
|
25
|
+
<a href="docs/ci-integration.md">CI Integration</a>
|
|
26
|
+
</p>
|
|
27
|
+
|
|
28
|
+
<p align="center">
|
|
29
|
+
<a href=".readiness/review-baseline.json">
|
|
30
|
+
<img src="https://img.shields.io/badge/ready-100%25-brightgreen" alt="ready: 100%" />
|
|
31
|
+
</a>
|
|
32
|
+
<img src="https://img.shields.io/badge/license-MIT-blue" alt="MIT License" />
|
|
33
|
+
</p>
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Connect with Jeremiah Walters
|
|
38
|
+
|
|
39
|
+
[](https://www.linkedin.com/in/jeremiahwalters)
|
|
40
|
+
[](https://x.com/Afrotechnician)
|
|
41
|
+
|
|
42
|
+
## The Problem: Velocity Outran Discipline
|
|
43
|
+
|
|
44
|
+
AI coding tools removed the friction from writing and shipping code. They did not remove the friction from the discipline work — health checks, secrets hygiene, on-call registration, telemetry coverage, auth on every endpoint. Velocity is now AI-speed. Discipline is still person-speed. The gap between the two is where incidents live.
|
|
45
|
+
|
|
46
|
+
Production breakdowns keep hitting strong engineering orgs — not because they lack talent, but because velocity outran the scaffolding. Smart teams moved fast, skipped the prep work, and found out later that the checks weren't there. `ready` is the tool that implements this practice. It replaces **prep work**, not judgment.
|
|
47
|
+
|
|
48
|
+
## Before / After
|
|
49
|
+
|
|
50
|
+
| Before | After |
|
|
51
|
+
|--------|-------|
|
|
52
|
+
| AI writes code in seconds; readiness checks take hours | Readiness checks run in the same pipeline, same pace |
|
|
53
|
+
| Manual checklists that can't keep up with AI velocity | Automated scan on every PR — no human bottleneck |
|
|
54
|
+
| Point-in-time review ceremonies | Continuous compliance, not a quarterly ritual |
|
|
55
|
+
| Drift detected by incidents | Drift detected before merge |
|
|
56
|
+
| Tribal knowledge of what's missing | Structured gap list with file-path evidence |
|
|
57
|
+
| "Are we ready?" is a subjective question | "Are we ready?" has a deterministic answer |
|
|
58
|
+
| Accepted risks forgotten over time | Accepted risks expire and re-surface automatically |
|
|
59
|
+
|
|
60
|
+
## Quickstart
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
pip install readiness-as-code
|
|
64
|
+
|
|
65
|
+
cd your-repo
|
|
66
|
+
ready scan
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
> **Windows / PATH issues?** Use `python -m ready scan` — works anywhere Python is installed.
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
ready? — your-service 80% 1 blocking · 2 warnings
|
|
73
|
+
|
|
74
|
+
✗ No secrets in code
|
|
75
|
+
src/config.py:14
|
|
76
|
+
→ Remove hardcoded keys. Use environment variables or a secrets manager.
|
|
77
|
+
|
|
78
|
+
+ 2 warnings (ready scan --verbose)
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
**No config. No accounts. No init required.** `ready scan` auto-detects your project type and runs immediately. When you're ready to customize, run `ready init`.
|
|
82
|
+
|
|
83
|
+
When everything is passing:
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
ready? — your-service 100% ✓ ▲ +12%
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
One line. The drift indicator appears automatically whenever a committed baseline exists.
|
|
90
|
+
|
|
91
|
+
## Origin
|
|
92
|
+
|
|
93
|
+
Built from production use managing 86+ readiness checkpoints across enterprise reliability engineering at scale. This is the vendor-neutral, portable version of a system that enforces production readiness across real services handling real incidents — not a weekend experiment.
|
|
94
|
+
|
|
95
|
+
## How It Works
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
your-repo/
|
|
99
|
+
└── .readiness/
|
|
100
|
+
├── checkpoint-definitions.json # What to check
|
|
101
|
+
├── exceptions.json # Accepted risks + expiry
|
|
102
|
+
├── external-evidence.json # Human attestations for non-code artifacts
|
|
103
|
+
└── review-baseline.json # Last scan snapshot (committed = audit trail)
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
Four JSON files and a scanner. Checkpoints resolve through three verification types: **code checks** (grep/glob/file_exists against the repo), **external checks** (human attestations for artifacts outside the repo), and **hybrid checks** (both must pass). → [Architecture details](docs/architecture-and-tradeoffs.md) · [Verification types](docs/verification-types.md)
|
|
107
|
+
|
|
108
|
+
## Checkpoint Packs
|
|
109
|
+
|
|
110
|
+
Start with a curated pack, then customize:
|
|
111
|
+
|
|
112
|
+
```bash
|
|
113
|
+
ready init # Universal starter (default)
|
|
114
|
+
ready init --pack web-api # REST/HTTP API checks
|
|
115
|
+
ready init --pack security-baseline # Secrets, dependency hygiene, security policy
|
|
116
|
+
ready init --pack telemetry # Logging, tracing, metrics, dashboards
|
|
117
|
+
ready init --pack engineering-review # Full engineering review (arch, security, testing, AI/RAI)
|
|
118
|
+
ready init --pack operational-review # Operational readiness (SLOs, on-call, data, capacity)
|
|
119
|
+
ready init --pack governance # SDLC gates + external review attestations
|
|
120
|
+
ready init --pack service-migration # Service identity migration, auth provisioning, cutover
|
|
121
|
+
ready init --list-packs # Show all available packs
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
| Pack | Checks | Best for |
|
|
125
|
+
|------|--------|----------|
|
|
126
|
+
| `starter` | 11 | Any repo |
|
|
127
|
+
| `web-api` | 17 | REST/HTTP services |
|
|
128
|
+
| `security-baseline` | 8 | Any repo with sensitive data |
|
|
129
|
+
| `telemetry` | 8 | Production services |
|
|
130
|
+
| `engineering-review` | 26 | Pre-launch engineering review |
|
|
131
|
+
| `operational-review` | 14 | Pre-launch operational review |
|
|
132
|
+
| `governance` | 15 | SDLC compliance + sign-off tracking |
|
|
133
|
+
| `service-migration` | 9 | Service identity migration + cutover |
|
|
134
|
+
|
|
135
|
+
## Proven in Production
|
|
136
|
+
|
|
137
|
+
ready is based on a system used in enterprise reliability engineering environments,
|
|
138
|
+
enforcing 80+ readiness checkpoints across real services.
|
|
139
|
+
|
|
140
|
+
It has been used to:
|
|
141
|
+
- continuously evaluate production readiness across services
|
|
142
|
+
- detect regression before deployment
|
|
143
|
+
- reduce reliance on manual review preparation
|
|
144
|
+
|
|
145
|
+
This open-source version is the portable, vendor-neutral implementation.
|
|
146
|
+
|
|
147
|
+
## Key Capabilities
|
|
148
|
+
|
|
149
|
+
- **Auto-drift detection.** If a committed baseline exists, every scan shows a delta: `▲ +12%` or `▼ -5%`. No flags, no extra commands.
|
|
150
|
+
- **Closed-loop work item tracking.** Gaps become tracked work items (GitHub, Azure DevOps, Jira); ticket-closed-but-code-failing flags as **regression**, code-fixed-but-ticket-open as **stale**.
|
|
151
|
+
- **Cross-repo aggregation.** `ready aggregate` turns multiple baselines into an HTML heatmap — *"telemetry gaps in 4 of 5 services"* is a platform problem, not a team problem.
|
|
152
|
+
- **Expiring accepted risks.** Acknowledge a gap with a justification and expiry date; the scanner re-flags it when the expiry passes.
|
|
153
|
+
- **Readiness audit.** `ready audit` reports the health of the readiness system itself — exception age, definition staleness, review_by coverage, score trend.
|
|
154
|
+
- **Codebase-aware inference.** `ready infer` analyzes stack, frameworks, dependencies, ADRs, and auth patterns to propose tailored checkpoints you approve one at a time.
|
|
155
|
+
- **AI-assisted authoring.** `ready author --from guidelines.md` generates a paste-ready prompt for any model (Claude, ChatGPT, Copilot, Cursor, Gemini).
|
|
156
|
+
- **README badge.** `ready badge` generates a shields.io badge from the committed score.
|
|
157
|
+
- **CI gating.** Non-zero exit on red failures; templates for GitHub Actions, Azure Pipelines, GitLab CI. → [Details](docs/ci-integration.md)
|
|
158
|
+
- **Azure DevOps extension.** Pipeline task publishes each checkpoint as a test case, plus a dashboard widget for score, trend, and blocking count. → [Details](ado-extension/README.md)
|
|
159
|
+
|
|
160
|
+
## What This Is Not
|
|
161
|
+
|
|
162
|
+
- **Not a static analysis tool.** SonarQube checks code quality. This checks whether your service meets its review requirements.
|
|
163
|
+
- **Not a policy engine.** OPA/Sentinel enforce infra policies at deploy time. This tracks operational and engineering readiness across code and non-code artifacts.
|
|
164
|
+
- **Not a compliance SaaS.** Drata/RegScale automate regulatory frameworks. This enforces your team's own internal review standards.
|
|
165
|
+
- **Not a replacement for AI coding tools.** It's the complement to them — the discipline layer that keeps pace with the velocity they enable.
|
|
166
|
+
- **Not a replacement for review meetings.** This replaces the prep work so the meeting can focus on judgment calls the scanner can't make.
|
|
167
|
+
|
|
168
|
+
## Commands
|
|
169
|
+
|
|
170
|
+
```bash
|
|
171
|
+
# Scanning
|
|
172
|
+
ready scan # Score + blocking items
|
|
173
|
+
ready scan --verbose # Full detail — all checks, evidence, fix hints
|
|
174
|
+
ready scan --calibrate # Report-only (no exit code failure)
|
|
175
|
+
ready scan --json # Machine-readable output
|
|
176
|
+
ready scan --baseline FILE # Write baseline snapshot (enables drift tracking)
|
|
177
|
+
ready scan --suggest-tuning # Show pattern tuning suggestions after scan
|
|
178
|
+
|
|
179
|
+
# Setup
|
|
180
|
+
ready init # Scaffold .readiness/ with starter pack
|
|
181
|
+
ready init --pack web-api # Scaffold with a specific pack
|
|
182
|
+
ready init --list-packs # List available packs
|
|
183
|
+
|
|
184
|
+
# Authoring & inference
|
|
185
|
+
ready infer # Analyze codebase → propose tailored checkpoints (human approves each)
|
|
186
|
+
ready author --from FILE # Generate AI prompt from a guideline document
|
|
187
|
+
|
|
188
|
+
# Audit trail
|
|
189
|
+
ready badge # Generate README badge from current score
|
|
190
|
+
ready decisions # Show all active, expiring, and expired exceptions
|
|
191
|
+
ready history [BASELINES...] # Show readiness trend from baseline snapshots
|
|
192
|
+
ready audit # Audit exception health, definition staleness, and score health
|
|
193
|
+
|
|
194
|
+
# Work items
|
|
195
|
+
ready items --create # Propose + create work items (human approves each)
|
|
196
|
+
ready items --verify # Cross-check work items vs code
|
|
197
|
+
|
|
198
|
+
# Cross-repo
|
|
199
|
+
ready aggregate PATHS... # Cross-repo heatmap from multiple baselines
|
|
200
|
+
ready aggregate PATHS... --html # Generate self-contained HTML heatmap report
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
## AI Integration
|
|
204
|
+
|
|
205
|
+
ready ships a [Model Context Protocol](https://modelcontextprotocol.io) server (`ready-mcp`) so any MCP client — Claude, Cursor, Copilot — can run scans and inspect checkpoints directly.
|
|
206
|
+
|
|
207
|
+
```bash
|
|
208
|
+
pip install "readiness-as-code[mcp]"
|
|
209
|
+
ready-mcp
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
| Tool | Description |
|
|
213
|
+
|------|-------------|
|
|
214
|
+
| `scan_repo` | Full readiness scan with results |
|
|
215
|
+
| `list_checkpoints` | View all checkpoint definitions |
|
|
216
|
+
| `explain_checkpoint` | Deep-dive on a specific check |
|
|
217
|
+
| `aggregate_baselines` | Cross-repo heatmap for systemic gap detection |
|
|
218
|
+
|
|
219
|
+
For prompt-based authoring with any model:
|
|
220
|
+
|
|
221
|
+
```bash
|
|
222
|
+
ready author --from docs/ops-review.md # generates author-prompt.md, paste into any AI
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
**→ [MCP setup for Claude Desktop, Cursor, VS Code](mcp/README.md)**
|
|
226
|
+
|
|
227
|
+
## Design Principles
|
|
228
|
+
|
|
229
|
+
These principles define what *readiness as code* means in practice. They are not implementation choices — they are the practice itself.
|
|
230
|
+
|
|
231
|
+
1. **Detection, not decisions.** The scanner finds gaps. Humans decide what to do.
|
|
232
|
+
2. **Continuous, not ceremonial.** Checked on every PR, not once a quarter.
|
|
233
|
+
3. **Velocity-aware, not velocity-hostile.** Designed to run at the speed of AI-assisted development — no human bottleneck in the loop.
|
|
234
|
+
4. **Portable, not hosted.** Files in your repo. No infrastructure.
|
|
235
|
+
5. **Evidence-backed, not trust-based.** Every assertion has a file path, attestation, or work item.
|
|
236
|
+
6. **Expiring, not permanent.** Accepted risks have expiry dates. Nothing is forever.
|
|
237
|
+
7. **Score-first, not report-first.** The answer to "are we ready?" is one line. Detail is on demand.
|
|
238
|
+
|
|
239
|
+
## Contributing
|
|
240
|
+
|
|
241
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
242
|
+
|
|
243
|
+
## License
|
|
244
|
+
|
|
245
|
+
[MIT](LICENSE)
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
[build-system]
|
|
2
|
+
requires = ["setuptools>=68.0", "wheel"]
|
|
3
|
+
build-backend = "setuptools.build_meta"
|
|
4
|
+
|
|
5
|
+
[project]
|
|
6
|
+
name = "readiness-as-code"
|
|
7
|
+
version = "0.7.0"
|
|
8
|
+
description = "Know before you ship — continuous readiness as a folder in your repo."
|
|
9
|
+
readme = "README.md"
|
|
10
|
+
license = {text = "MIT"}
|
|
11
|
+
requires-python = ">=3.10"
|
|
12
|
+
authors = [
|
|
13
|
+
{name = "Jeremiah Walters"}
|
|
14
|
+
]
|
|
15
|
+
keywords = [
|
|
16
|
+
"compliance",
|
|
17
|
+
"code-review",
|
|
18
|
+
"quality-gates",
|
|
19
|
+
"operational-readiness",
|
|
20
|
+
"devops",
|
|
21
|
+
"ci-cd",
|
|
22
|
+
"policy-as-code",
|
|
23
|
+
]
|
|
24
|
+
classifiers = [
|
|
25
|
+
"Development Status :: 3 - Alpha",
|
|
26
|
+
"Intended Audience :: Developers",
|
|
27
|
+
"License :: OSI Approved :: MIT License",
|
|
28
|
+
"Programming Language :: Python :: 3",
|
|
29
|
+
"Programming Language :: Python :: 3.10",
|
|
30
|
+
"Programming Language :: Python :: 3.11",
|
|
31
|
+
"Programming Language :: Python :: 3.12",
|
|
32
|
+
"Topic :: Software Development :: Quality Assurance",
|
|
33
|
+
"Topic :: Software Development :: Testing",
|
|
34
|
+
]
|
|
35
|
+
|
|
36
|
+
[project.urls]
|
|
37
|
+
Homepage = "https://github.com/jtwalters25/readiness-as-code"
|
|
38
|
+
Documentation = "https://github.com/jtwalters25/readiness-as-code/tree/main/docs"
|
|
39
|
+
Repository = "https://github.com/jtwalters25/readiness-as-code"
|
|
40
|
+
Issues = "https://github.com/jtwalters25/readiness-as-code/issues"
|
|
41
|
+
|
|
42
|
+
[project.optional-dependencies]
|
|
43
|
+
mcp = ["mcp>=1.0"]
|
|
44
|
+
|
|
45
|
+
[project.scripts]
|
|
46
|
+
ready = "ready.ready:main"
|
|
47
|
+
ready-mcp = "ready.mcp_server:main"
|
|
48
|
+
|
|
49
|
+
[tool.setuptools.packages.find]
|
|
50
|
+
include = ["ready*"]
|
|
51
|
+
|
|
52
|
+
[tool.setuptools.package-data]
|
|
53
|
+
"*" = ["*.json", "*.yml", "*.yaml", "*.md"]
|
|
54
|
+
|
|
55
|
+
[tool.pytest.ini_options]
|
|
56
|
+
testpaths = ["tests"]
|
|
57
|
+
pythonpath = ["."]
|
|
58
|
+
|
|
59
|
+
[tool.ruff]
|
|
60
|
+
target-version = "py310"
|
|
61
|
+
line-length = 100
|