@esthernandez/vibe-doc 0.1.0 → 0.2.1
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.
- package/README.md +181 -0
- package/dist/index.js +3 -1
- package/package.json +18 -4
- package/dist/templates/embedded/adr.md +0 -45
- package/dist/templates/embedded/api-spec.md +0 -55
- package/dist/templates/embedded/data-model.md +0 -55
- package/dist/templates/embedded/deployment-procedure.md +0 -63
- package/dist/templates/embedded/runbook.md +0 -55
- package/dist/templates/embedded/test-plan.md +0 -55
- package/dist/templates/embedded/threat-model.md +0 -47
package/README.md
ADDED
|
@@ -0,0 +1,181 @@
|
|
|
1
|
+
# Vibe Doc
|
|
2
|
+
|
|
3
|
+
AI-powered documentation gap analyzer for modern codebases. Scan your project, identify missing technical documentation, and generate professional docs from your existing artifacts in minutes.
|
|
4
|
+
|
|
5
|
+
## The Problem
|
|
6
|
+
|
|
7
|
+
Vibe coding produces real artifacts fast — working code, architecture decisions, test suites, deployment configs. But corporate documentation requirements don't care about your momentum. You need ADRs, runbooks, threat models, API specs, and deployment procedures. Writing them by hand is bureaucratic overhead. Ignoring them is a shipping risk.
|
|
8
|
+
|
|
9
|
+
Vibe Doc bridges the gap. It analyzes what you've actually built, finds the documentation holes, and generates the docs you need.
|
|
10
|
+
|
|
11
|
+
## How It Works
|
|
12
|
+
|
|
13
|
+
Vibe Doc operates in four stages:
|
|
14
|
+
|
|
15
|
+
1. **Scan** — Walk your codebase. Extract artifacts, identify patterns, build a project profile.
|
|
16
|
+
2. **Classify** — Hybrid classifier (rules + LLM) determines your project type and architecture patterns.
|
|
17
|
+
3. **Gap Analysis** — Cross-reference your artifacts against the 7-doc v1 standard. Generate a prioritized gap report.
|
|
18
|
+
4. **Generate** — Create missing docs from your existing code, configs, and conversations.
|
|
19
|
+
|
|
20
|
+
The dual-layer design means you get intelligent recommendations in conversations (Skills) and deterministic, reproducible outputs from the CLI.
|
|
21
|
+
|
|
22
|
+
## Installation
|
|
23
|
+
|
|
24
|
+
### As a Cowork/Claude Code Plugin
|
|
25
|
+
|
|
26
|
+
1. In Cowork or Claude Code, open the Plugins menu
|
|
27
|
+
2. Search for "Vibe Doc"
|
|
28
|
+
3. Click Install
|
|
29
|
+
4. Navigate to your project directory and run `/scan` to begin
|
|
30
|
+
|
|
31
|
+
### As a CLI
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
npm install -g @esthernandez/vibe-doc
|
|
35
|
+
# or
|
|
36
|
+
npx @esthernandez/vibe-doc scan
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
## Quick Start
|
|
40
|
+
|
|
41
|
+
### Step 1: Scan Your Project
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
/scan
|
|
45
|
+
# or via CLI:
|
|
46
|
+
npx vibe-doc scan
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Vibe Doc examines your codebase, classifies your architecture, and generates a gap report showing which docs are missing and their priority.
|
|
50
|
+
|
|
51
|
+
### Step 2: Review Gaps
|
|
52
|
+
|
|
53
|
+
The gap report categorizes findings by three tiers:
|
|
54
|
+
- **Required** — Essential for shipping (ADRs, deployment procedures)
|
|
55
|
+
- **Recommended** — Professional standard (runbooks, API specs, threat models)
|
|
56
|
+
- **Optional** — Nice-to-have (test plans, data models)
|
|
57
|
+
|
|
58
|
+
### Step 3: Generate
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
/generate
|
|
62
|
+
# or via CLI:
|
|
63
|
+
npx vibe-doc generate
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
Select which gaps to fill, review the generated docs, and refine them in conversation. Export to your repository.
|
|
67
|
+
|
|
68
|
+
## Available Skills
|
|
69
|
+
|
|
70
|
+
**Scan Skill**
|
|
71
|
+
Analyzes your project structure, detects architecture patterns, and generates a comprehensive gap report. Classifies your codebase (backend service, frontend app, monorepo, etc.) and identifies which documents are missing.
|
|
72
|
+
|
|
73
|
+
**Generate Skill**
|
|
74
|
+
Creates professional documentation from your artifacts. Takes scan results, your input on specific areas, and generates high-quality ADRs, runbooks, threat models, API specs, deployment procedures, test plans, and data models.
|
|
75
|
+
|
|
76
|
+
**Check Skill**
|
|
77
|
+
Validates that your documentation meets deployment requirements. Ensures all Required-tier docs exist, formatting is correct, and docs are up-to-date with current artifacts.
|
|
78
|
+
|
|
79
|
+
## Available Commands
|
|
80
|
+
|
|
81
|
+
`/scan` — Scan your project for documentation gaps and generate a report.
|
|
82
|
+
|
|
83
|
+
`/generate` — Generate missing documentation based on scan results.
|
|
84
|
+
|
|
85
|
+
`/check` — Validate documentation completeness for deployment readiness.
|
|
86
|
+
|
|
87
|
+
`/status` — Display current Vibe Doc state and recent activity.
|
|
88
|
+
|
|
89
|
+
## CLI Usage
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
# Scan your project
|
|
93
|
+
npx vibe-doc scan
|
|
94
|
+
|
|
95
|
+
# Generate documentation
|
|
96
|
+
npx vibe-doc generate
|
|
97
|
+
|
|
98
|
+
# Check deployment readiness
|
|
99
|
+
npx vibe-doc check
|
|
100
|
+
|
|
101
|
+
# Show status
|
|
102
|
+
npx vibe-doc status
|
|
103
|
+
|
|
104
|
+
# View available templates
|
|
105
|
+
npx vibe-doc templates
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
## Document Types (v1 Standard)
|
|
109
|
+
|
|
110
|
+
Vibe Doc generates seven core document types:
|
|
111
|
+
|
|
112
|
+
**Architecture Decision Record (ADR)**
|
|
113
|
+
Captures why a major architectural choice was made, its context, and trade-offs. Essential for onboarding and future decisions.
|
|
114
|
+
|
|
115
|
+
**Runbook**
|
|
116
|
+
Step-by-step operational procedures: deployment, incident response, disaster recovery, scaling. Keeps your ops team sane at 3am.
|
|
117
|
+
|
|
118
|
+
**Threat Model**
|
|
119
|
+
Security analysis of your system. What can go wrong? What are the attack surfaces? What's the risk profile?
|
|
120
|
+
|
|
121
|
+
**API Specification**
|
|
122
|
+
OpenAPI 3.0 or equivalent. Every endpoint, schema, auth method, error code. The contract between frontend and backend.
|
|
123
|
+
|
|
124
|
+
**Deployment Procedure**
|
|
125
|
+
How code gets from your laptop to production. Environments, prerequisites, rollback strategy, validation steps.
|
|
126
|
+
|
|
127
|
+
**Test Plan**
|
|
128
|
+
Unit, integration, E2E coverage strategy. What gets tested, what's out of scope, how you validate quality gates.
|
|
129
|
+
|
|
130
|
+
**Data Model**
|
|
131
|
+
Database schema, relationships, constraints, indexes. The shape of your state.
|
|
132
|
+
|
|
133
|
+
## Architecture Overview
|
|
134
|
+
|
|
135
|
+
Vibe Doc is built as a dual-layer system:
|
|
136
|
+
|
|
137
|
+
**Conversation Layer (Skills)**
|
|
138
|
+
Flexible, adaptive analysis using LLMs. Scan, classify, generate, refine. Everything happens in natural language with the user driving the direction.
|
|
139
|
+
|
|
140
|
+
**Deterministic Layer (CLI)**
|
|
141
|
+
Reproducible operations. Scans are cached and versioned. Generations are deterministic given the same inputs. Perfect for CI/CD integration and batch processing.
|
|
142
|
+
|
|
143
|
+
Both layers share the same classification engine and document templates, so you get consistent results whether you're in a conversation or running automated checks.
|
|
144
|
+
|
|
145
|
+
## Classification System
|
|
146
|
+
|
|
147
|
+
Projects vary wildly. Vibe Doc uses a hybrid classifier:
|
|
148
|
+
|
|
149
|
+
**Rules-based Layer**
|
|
150
|
+
Patterns that are obvious: presence of Dockerfiles, package.json structure, framework detection, cloud config patterns. Fast, deterministic, no hallucination.
|
|
151
|
+
|
|
152
|
+
**LLM Fallback**
|
|
153
|
+
When patterns are ambiguous or custom, ask Claude. Classifies your project type, architecture style, and risk profile based on artifacts and code structure.
|
|
154
|
+
|
|
155
|
+
The result is a project profile that guides both gap analysis and doc generation.
|
|
156
|
+
|
|
157
|
+
## Three-Tier Priority System
|
|
158
|
+
|
|
159
|
+
Every gap gets a priority:
|
|
160
|
+
|
|
161
|
+
**Required** — Must exist before shipping. Includes ADRs for major decisions, deployment procedures, and API specs if you have an API surface. Typically 2-3 docs.
|
|
162
|
+
|
|
163
|
+
**Recommended** — Professional standard. Runbooks, threat models, test plans. Makes your codebase maintainable and professional. Typically 3-4 docs.
|
|
164
|
+
|
|
165
|
+
**Optional** — Nice-to-have. Data models for internal use, architectural diagrams, backup procedures. Typically 1-2 docs.
|
|
166
|
+
|
|
167
|
+
This means you can ship after filling Required docs, improve gradually with Recommended, and polish with Optional.
|
|
168
|
+
|
|
169
|
+
## Works Independently or Together
|
|
170
|
+
|
|
171
|
+
Vibe Doc is part of the **626Labs plugin ecosystem**. It runs standalone or alongside other 626Labs plugins like [`@esthernandez/app-project-readiness`](https://www.npmjs.com/package/@esthernandez/app-project-readiness) — when both are installed, they share a **unified builder profile** at `~/.claude/profiles/builder.json` so you only onboard once across all 626Labs plugins.
|
|
172
|
+
|
|
173
|
+
Vibe Doc respects the [Self-Evolving Plugin Framework](docs/self-evolving-plugins-framework.md) — it reads the shared profile to calibrate tone and depth, writes only to its own `plugins.vibe-doc` namespace, and never stomps other plugins' data. See the framework doc for the full thesis, 12-pattern catalog, and applied playbook.
|
|
174
|
+
|
|
175
|
+
## Contributing
|
|
176
|
+
|
|
177
|
+
Found a bug? Missing a document type? Want to improve the classifier? Open an issue or PR at [the Vibe Doc repository](https://github.com/estevanhernandez-stack-ed/Vibe-Doc).
|
|
178
|
+
|
|
179
|
+
## License
|
|
180
|
+
|
|
181
|
+
MIT
|
package/dist/index.js
CHANGED
|
@@ -50,10 +50,12 @@ const generator_1 = require("./generator");
|
|
|
50
50
|
const templates_1 = require("./templates");
|
|
51
51
|
const extractor_1 = require("./generator/extractor");
|
|
52
52
|
const program = new commander_1.Command();
|
|
53
|
+
const pkgJsonPath = path.resolve(__dirname, '..', 'package.json');
|
|
54
|
+
const pkgVersion = JSON.parse(fs.readFileSync(pkgJsonPath, 'utf-8')).version;
|
|
53
55
|
program
|
|
54
56
|
.name('vibe-doc')
|
|
55
57
|
.description('AI-powered documentation gap analyzer for any codebase')
|
|
56
|
-
.version(
|
|
58
|
+
.version(pkgVersion);
|
|
57
59
|
/**
|
|
58
60
|
* Scan command: Run artifact scanner and save inventory
|
|
59
61
|
*/
|
package/package.json
CHANGED
|
@@ -1,16 +1,30 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@esthernandez/vibe-doc",
|
|
3
|
-
"version": "0.1
|
|
4
|
-
"description": "
|
|
5
|
-
"author": "
|
|
3
|
+
"version": "0.2.1",
|
|
4
|
+
"description": "AI-powered documentation gap analyzer and generator for modern codebases. Scans your project, classifies your architecture, and generates professional docs from your existing artifacts.",
|
|
5
|
+
"author": "626Labs LLC",
|
|
6
6
|
"license": "MIT",
|
|
7
|
+
"keywords": [
|
|
8
|
+
"documentation",
|
|
9
|
+
"doc-generator",
|
|
10
|
+
"ai-docs",
|
|
11
|
+
"claude-code-plugin",
|
|
12
|
+
"626labs"
|
|
13
|
+
],
|
|
14
|
+
"repository": {
|
|
15
|
+
"type": "git",
|
|
16
|
+
"url": "https://github.com/estevanhernandez-stack-ed/Vibe-Doc.git"
|
|
17
|
+
},
|
|
18
|
+
"homepage": "https://github.com/estevanhernandez-stack-ed/Vibe-Doc#readme",
|
|
19
|
+
"bugs": "https://github.com/estevanhernandez-stack-ed/Vibe-Doc/issues",
|
|
7
20
|
"bin": {
|
|
8
21
|
"vibe-doc": "./dist/index.js"
|
|
9
22
|
},
|
|
10
23
|
"main": "./dist/index.js",
|
|
11
24
|
"types": "./dist/index.d.ts",
|
|
12
25
|
"files": [
|
|
13
|
-
"dist"
|
|
26
|
+
"dist",
|
|
27
|
+
"README.md"
|
|
14
28
|
],
|
|
15
29
|
"scripts": {
|
|
16
30
|
"build": "tsc && npm run build:copy-templates",
|
|
@@ -1,45 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: adr
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Architecture Decision Record
|
|
8
|
-
|
|
9
|
-
## Status
|
|
10
|
-
|
|
11
|
-
{{user.status}}
|
|
12
|
-
|
|
13
|
-
<!-- NEEDS INPUT: What is the status of this decision? (Proposed, Accepted, Deprecated, Superseded) -->
|
|
14
|
-
|
|
15
|
-
## Context
|
|
16
|
-
|
|
17
|
-
{{extracted.context}}
|
|
18
|
-
|
|
19
|
-
{{user.context}}
|
|
20
|
-
|
|
21
|
-
<!-- NEEDS INPUT: What is the issue that motivated this decision or any context you should record here? -->
|
|
22
|
-
|
|
23
|
-
## Decision
|
|
24
|
-
|
|
25
|
-
{{extracted.decision}}
|
|
26
|
-
|
|
27
|
-
{{user.decision}}
|
|
28
|
-
|
|
29
|
-
<!-- NEEDS INPUT: What is the change that we're proposing or have agreed to do? -->
|
|
30
|
-
|
|
31
|
-
## Consequences
|
|
32
|
-
|
|
33
|
-
{{extracted.consequences}}
|
|
34
|
-
|
|
35
|
-
{{user.consequences}}
|
|
36
|
-
|
|
37
|
-
<!-- NEEDS INPUT: What becomes easier or more difficult to do because of this change? Include positive and negative consequences. -->
|
|
38
|
-
|
|
39
|
-
## Alternatives
|
|
40
|
-
|
|
41
|
-
{{extracted.alternatives}}
|
|
42
|
-
|
|
43
|
-
{{user.alternatives}}
|
|
44
|
-
|
|
45
|
-
<!-- NEEDS INPUT: What other options did you consider and why were they rejected? -->
|
|
@@ -1,55 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: api-spec
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# API Specification
|
|
8
|
-
|
|
9
|
-
## Base URL
|
|
10
|
-
|
|
11
|
-
{{extracted.base-url}}
|
|
12
|
-
|
|
13
|
-
{{user.base-url}}
|
|
14
|
-
|
|
15
|
-
<!-- NEEDS INPUT: What is the base URL for your API? Include protocol, hostname, and port. -->
|
|
16
|
-
|
|
17
|
-
## Endpoints
|
|
18
|
-
|
|
19
|
-
{{extracted.endpoints}}
|
|
20
|
-
|
|
21
|
-
{{user.endpoints}}
|
|
22
|
-
|
|
23
|
-
<!-- NEEDS INPUT: List your primary endpoints. Include HTTP method, path, and brief description. -->
|
|
24
|
-
|
|
25
|
-
## Request Format
|
|
26
|
-
|
|
27
|
-
{{extracted.request-format}}
|
|
28
|
-
|
|
29
|
-
{{user.request-format}}
|
|
30
|
-
|
|
31
|
-
<!-- NEEDS INPUT: Describe the request format. Include content-type, headers, body structure, and examples. -->
|
|
32
|
-
|
|
33
|
-
## Response Format
|
|
34
|
-
|
|
35
|
-
{{extracted.response-format}}
|
|
36
|
-
|
|
37
|
-
{{user.response-format}}
|
|
38
|
-
|
|
39
|
-
<!-- NEEDS INPUT: Describe the response format. Include status codes, body structure, headers, and examples. -->
|
|
40
|
-
|
|
41
|
-
## Error Handling
|
|
42
|
-
|
|
43
|
-
{{extracted.error-handling}}
|
|
44
|
-
|
|
45
|
-
{{user.error-handling}}
|
|
46
|
-
|
|
47
|
-
<!-- NEEDS INPUT: How do you handle errors? Include error codes, error message format, and common errors. -->
|
|
48
|
-
|
|
49
|
-
## Authentication
|
|
50
|
-
|
|
51
|
-
{{extracted.authentication}}
|
|
52
|
-
|
|
53
|
-
{{user.authentication}}
|
|
54
|
-
|
|
55
|
-
<!-- NEEDS INPUT: How do clients authenticate? Include auth mechanisms, required headers, and token formats. -->
|
|
@@ -1,55 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: data-model
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Data Model
|
|
8
|
-
|
|
9
|
-
## Entity Overview
|
|
10
|
-
|
|
11
|
-
{{extracted.entity-overview}}
|
|
12
|
-
|
|
13
|
-
{{user.entity-overview}}
|
|
14
|
-
|
|
15
|
-
<!-- NEEDS INPUT: What are the main entities/tables in your data model? Include brief descriptions of each. -->
|
|
16
|
-
|
|
17
|
-
## Table Schemas
|
|
18
|
-
|
|
19
|
-
{{extracted.table-schemas}}
|
|
20
|
-
|
|
21
|
-
{{user.table-schemas}}
|
|
22
|
-
|
|
23
|
-
<!-- NEEDS INPUT: Describe the schema for each table. Include column names, types, and descriptions. -->
|
|
24
|
-
|
|
25
|
-
## Relationships
|
|
26
|
-
|
|
27
|
-
{{extracted.relationships}}
|
|
28
|
-
|
|
29
|
-
{{user.relationships}}
|
|
30
|
-
|
|
31
|
-
<!-- NEEDS INPUT: What are the relationships between tables? Include foreign keys and cardinality. -->
|
|
32
|
-
|
|
33
|
-
## Constraints
|
|
34
|
-
|
|
35
|
-
{{extracted.constraints}}
|
|
36
|
-
|
|
37
|
-
{{user.constraints}}
|
|
38
|
-
|
|
39
|
-
<!-- NEEDS INPUT: What constraints and validation rules exist? Include unique constraints, check constraints, and business rules. -->
|
|
40
|
-
|
|
41
|
-
## Indexes
|
|
42
|
-
|
|
43
|
-
{{extracted.indexes}}
|
|
44
|
-
|
|
45
|
-
{{user.indexes}}
|
|
46
|
-
|
|
47
|
-
<!-- NEEDS INPUT: What indexes exist and why? Include primary keys, unique indexes, and performance indexes. -->
|
|
48
|
-
|
|
49
|
-
## Migration Strategy
|
|
50
|
-
|
|
51
|
-
{{extracted.migration-strategy}}
|
|
52
|
-
|
|
53
|
-
{{user.migration-strategy}}
|
|
54
|
-
|
|
55
|
-
<!-- NEEDS INPUT: How do you handle schema migrations? Include versioning, rollback strategy, and zero-downtime deployment. -->
|
|
@@ -1,63 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: deployment-procedure
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Deployment Procedure
|
|
8
|
-
|
|
9
|
-
## Prerequisites
|
|
10
|
-
|
|
11
|
-
{{extracted.prerequisites}}
|
|
12
|
-
|
|
13
|
-
{{user.prerequisites}}
|
|
14
|
-
|
|
15
|
-
<!-- NEEDS INPUT: What prerequisites must be met before deployment? Include access, tools, accounts, and configurations. -->
|
|
16
|
-
|
|
17
|
-
## Build Process
|
|
18
|
-
|
|
19
|
-
{{extracted.build-process}}
|
|
20
|
-
|
|
21
|
-
{{user.build-process}}
|
|
22
|
-
|
|
23
|
-
<!-- NEEDS INPUT: What are the steps to build the application? Include compilation, dependency installation, and artifact generation. -->
|
|
24
|
-
|
|
25
|
-
## Environment Setup
|
|
26
|
-
|
|
27
|
-
{{extracted.environment-setup}}
|
|
28
|
-
|
|
29
|
-
{{user.environment-setup}}
|
|
30
|
-
|
|
31
|
-
<!-- NEEDS INPUT: What environment variables, secrets, and configurations are required for each environment? -->
|
|
32
|
-
|
|
33
|
-
## Testing Before Deploy
|
|
34
|
-
|
|
35
|
-
{{extracted.testing-before-deploy}}
|
|
36
|
-
|
|
37
|
-
{{user.testing-before-deploy}}
|
|
38
|
-
|
|
39
|
-
<!-- NEEDS INPUT: What tests and validations run before deployment? Include smoke tests, integration tests, and health checks. -->
|
|
40
|
-
|
|
41
|
-
## Deployment Steps
|
|
42
|
-
|
|
43
|
-
{{extracted.deployment-steps}}
|
|
44
|
-
|
|
45
|
-
{{user.deployment-steps}}
|
|
46
|
-
|
|
47
|
-
<!-- NEEDS INPUT: What are the step-by-step deployment instructions? Include database migrations, service restarts, and traffic shifting. -->
|
|
48
|
-
|
|
49
|
-
## Post-Deployment Checks
|
|
50
|
-
|
|
51
|
-
{{extracted.post-deployment-checks}}
|
|
52
|
-
|
|
53
|
-
{{user.post-deployment-checks}}
|
|
54
|
-
|
|
55
|
-
<!-- NEEDS INPUT: What checks verify the deployment was successful? Include health checks, endpoint tests, and monitoring. -->
|
|
56
|
-
|
|
57
|
-
## Rollback Procedure
|
|
58
|
-
|
|
59
|
-
{{extracted.rollback-procedure}}
|
|
60
|
-
|
|
61
|
-
{{user.rollback-procedure}}
|
|
62
|
-
|
|
63
|
-
<!-- NEEDS INPUT: How do you rollback to the previous version? Include steps, data rollback, and communication plan. -->
|
|
@@ -1,55 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: runbook
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Runbook
|
|
8
|
-
|
|
9
|
-
## Service Overview
|
|
10
|
-
|
|
11
|
-
{{extracted.service-overview}}
|
|
12
|
-
|
|
13
|
-
{{user.service-overview}}
|
|
14
|
-
|
|
15
|
-
<!-- NEEDS INPUT: What does this service do? What is its primary responsibility? -->
|
|
16
|
-
|
|
17
|
-
## Startup Procedure
|
|
18
|
-
|
|
19
|
-
{{extracted.startup-procedure}}
|
|
20
|
-
|
|
21
|
-
{{user.startup-procedure}}
|
|
22
|
-
|
|
23
|
-
<!-- NEEDS INPUT: What are the steps to start the service? Include environment setup, dependencies, configuration. -->
|
|
24
|
-
|
|
25
|
-
## Health Checks
|
|
26
|
-
|
|
27
|
-
{{extracted.health-checks}}
|
|
28
|
-
|
|
29
|
-
{{user.health-checks}}
|
|
30
|
-
|
|
31
|
-
<!-- NEEDS INPUT: How do you verify the service is healthy? What are the key metrics or checks? -->
|
|
32
|
-
|
|
33
|
-
## Common Issues
|
|
34
|
-
|
|
35
|
-
{{extracted.common-issues}}
|
|
36
|
-
|
|
37
|
-
{{user.common-issues}}
|
|
38
|
-
|
|
39
|
-
<!-- NEEDS INPUT: What are the most common problems and their solutions? -->
|
|
40
|
-
|
|
41
|
-
## Rollback Procedure
|
|
42
|
-
|
|
43
|
-
{{extracted.rollback-procedure}}
|
|
44
|
-
|
|
45
|
-
{{user.rollback-procedure}}
|
|
46
|
-
|
|
47
|
-
<!-- NEEDS INPUT: How do you roll back to a previous version? What steps are required? -->
|
|
48
|
-
|
|
49
|
-
## Escalation Path
|
|
50
|
-
|
|
51
|
-
{{extracted.escalation-path}}
|
|
52
|
-
|
|
53
|
-
{{user.escalation-path}}
|
|
54
|
-
|
|
55
|
-
<!-- NEEDS INPUT: Who should be contacted for different severity levels? What is the on-call process? -->
|
|
@@ -1,55 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: test-plan
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Test Plan
|
|
8
|
-
|
|
9
|
-
## Test Strategy
|
|
10
|
-
|
|
11
|
-
{{extracted.test-strategy}}
|
|
12
|
-
|
|
13
|
-
{{user.test-strategy}}
|
|
14
|
-
|
|
15
|
-
<!-- NEEDS INPUT: What is your overall testing strategy? Include testing levels, approach, and priorities. -->
|
|
16
|
-
|
|
17
|
-
## Unit Tests
|
|
18
|
-
|
|
19
|
-
{{extracted.unit-tests}}
|
|
20
|
-
|
|
21
|
-
{{user.unit-tests}}
|
|
22
|
-
|
|
23
|
-
<!-- NEEDS INPUT: What components and functions are covered by unit tests? Include test coverage goals. -->
|
|
24
|
-
|
|
25
|
-
## Integration Tests
|
|
26
|
-
|
|
27
|
-
{{extracted.integration-tests}}
|
|
28
|
-
|
|
29
|
-
{{user.integration-tests}}
|
|
30
|
-
|
|
31
|
-
<!-- NEEDS INPUT: What system interactions are tested? Include database, APIs, and third-party services. -->
|
|
32
|
-
|
|
33
|
-
## E2E Tests
|
|
34
|
-
|
|
35
|
-
{{extracted.e2e-tests}}
|
|
36
|
-
|
|
37
|
-
{{user.e2e-tests}}
|
|
38
|
-
|
|
39
|
-
<!-- NEEDS INPUT: What critical user workflows are tested end-to-end? Include scenarios and acceptance criteria. -->
|
|
40
|
-
|
|
41
|
-
## Performance Tests
|
|
42
|
-
|
|
43
|
-
{{extracted.performance-tests}}
|
|
44
|
-
|
|
45
|
-
{{user.performance-tests}}
|
|
46
|
-
|
|
47
|
-
<!-- NEEDS INPUT: What performance characteristics are tested? Include load tests, latency targets, and throughput. -->
|
|
48
|
-
|
|
49
|
-
## Coverage Targets
|
|
50
|
-
|
|
51
|
-
{{extracted.coverage-targets}}
|
|
52
|
-
|
|
53
|
-
{{user.coverage-targets}}
|
|
54
|
-
|
|
55
|
-
<!-- NEEDS INPUT: What are your code coverage targets? Include overall target and critical areas. -->
|
|
@@ -1,47 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
docType: threat-model
|
|
3
|
-
version: 1.0
|
|
4
|
-
templateVersion: 1
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Threat Model
|
|
8
|
-
|
|
9
|
-
## Asset Scope
|
|
10
|
-
|
|
11
|
-
{{extracted.asset-scope}}
|
|
12
|
-
|
|
13
|
-
{{user.asset-scope}}
|
|
14
|
-
|
|
15
|
-
<!-- NEEDS INPUT: What are the valuable assets you need to protect? Include data, infrastructure, and systems. -->
|
|
16
|
-
|
|
17
|
-
## Threat Actors
|
|
18
|
-
|
|
19
|
-
{{extracted.threat-actors}}
|
|
20
|
-
|
|
21
|
-
{{user.threat-actors}}
|
|
22
|
-
|
|
23
|
-
<!-- NEEDS INPUT: Who are the potential threat actors? (e.g., external attackers, malicious insiders, nation-states) -->
|
|
24
|
-
|
|
25
|
-
## Threat Scenarios
|
|
26
|
-
|
|
27
|
-
{{extracted.threat-scenarios}}
|
|
28
|
-
|
|
29
|
-
{{user.threat-scenarios}}
|
|
30
|
-
|
|
31
|
-
<!-- NEEDS INPUT: What are the specific threat scenarios you are concerned about? How might they compromise your assets? -->
|
|
32
|
-
|
|
33
|
-
## Mitigations
|
|
34
|
-
|
|
35
|
-
{{extracted.mitigations}}
|
|
36
|
-
|
|
37
|
-
{{user.mitigations}}
|
|
38
|
-
|
|
39
|
-
<!-- NEEDS INPUT: What controls do you have in place to mitigate these threats? Include technical, process, and organizational controls. -->
|
|
40
|
-
|
|
41
|
-
## Residual Risks
|
|
42
|
-
|
|
43
|
-
{{extracted.residual-risks}}
|
|
44
|
-
|
|
45
|
-
{{user.residual-risks}}
|
|
46
|
-
|
|
47
|
-
<!-- NEEDS INPUT: What risks remain after implementing mitigations? What is your risk tolerance? -->
|