@michaelmusyoka/eng-os-kit 1.0.0
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 +104 -0
- package/bin/eng-os.mjs +222 -0
- package/lib/targets.mjs +49 -0
- package/package.json +14 -0
- package/rules/engineering-contract.md +51 -0
- package/scripts/capture-evidence.sh +38 -0
- package/scripts/placeholder-audit.sh +51 -0
- package/scripts/validate-registry.mjs +71 -0
- package/skills/api-database-contract/SKILL.md +38 -0
- package/skills/code-review/SKILL.md +39 -0
- package/skills/engineering-contract/SKILL.md +40 -0
- package/skills/engineering-contract/references/definition-of-done.md +47 -0
- package/skills/implementation-prompt/SKILL.md +38 -0
- package/skills/incident-response/SKILL.md +34 -0
- package/skills/release-gate/SKILL.md +30 -0
- package/skills/repo-inspection/SKILL.md +41 -0
- package/skills/security-review/SKILL.md +43 -0
- package/skills/security-review/references/prompt-injection.md +18 -0
- package/skills/signature-dark-ui/SKILL.md +72 -0
- package/skills/signature-dark-ui/references/components.md +449 -0
- package/skills/signature-dark-ui/references/layout-and-motion.md +1246 -0
- package/skills/test-strategy/SKILL.md +36 -0
- package/skills/traceability-audit/SKILL.md +46 -0
- package/skills/verification-evidence/SKILL.md +30 -0
- package/state/decision-log.md +6 -0
- package/state/feature-registry.json +18 -0
- package/state/feature-registry.schema.json +29 -0
- package/state/known-issues.md +6 -0
- package/templates/adr.md +19 -0
- package/templates/feature-record.md +40 -0
- package/templates/implementation-prompt.md +49 -0
- package/templates/incident-report.md +29 -0
- package/templates/verification-record.md +45 -0
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: test-strategy
|
|
3
|
+
description: What to test, at which layer, and how to prove a critical workflow actually works end to end including failure paths. Use this whenever writing or reviewing tests, when asked whether something is tested enough, before declaring a feature verified, and when a bug is found (it needs a regression test). Load this instead of guessing at coverage.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Test Strategy
|
|
7
|
+
|
|
8
|
+
## Layers
|
|
9
|
+
Static checks → unit → integration → contract/API → E2E → security → performance → production smoke. Run what is applicable; state which you skipped and why.
|
|
10
|
+
|
|
11
|
+
- **Unit**: business rules, validation, calculations, state transitions, authorization decisions, error branches.
|
|
12
|
+
- **Integration**: real database, real adapters, real queue. A test that mocks the database does not prove persistence.
|
|
13
|
+
- **Contract/API**: request and response schemas, status codes, error bodies, pagination.
|
|
14
|
+
- **E2E**: critical journeys only, from the user's perspective — registration, login, recovery, the core transaction, checkout/payment, cancellation, refund, admin action.
|
|
15
|
+
|
|
16
|
+
## Every critical workflow needs
|
|
17
|
+
happy path · invalid input · missing input · unauthenticated · forbidden · missing resource · duplicate request · concurrent request · timeout · dependency failure · retry · recovery.
|
|
18
|
+
|
|
19
|
+
If only the happy path is tested, the feature is not tested.
|
|
20
|
+
|
|
21
|
+
## UI interaction audit
|
|
22
|
+
For every button, link, form, search, filter, pagination control, modal and nav control, verify: correct action fired · permission enforced · request actually sent · validation triggered · loading state blocks double submit · success state · failure state · persistence survives reload · UI reflects server truth.
|
|
23
|
+
|
|
24
|
+
A control that changes only local state is unimplemented.
|
|
25
|
+
|
|
26
|
+
## Assertions
|
|
27
|
+
Assert the outcome, not the call. `expect(db.orders.count()).toBe(1)` beats `expect(createOrder).toHaveBeenCalled()`. Assert the absence of the wrong thing too: no second record, no notification on failure, no state change on a 403.
|
|
28
|
+
|
|
29
|
+
## Coverage
|
|
30
|
+
Coverage is evidence, not correctness. Critical business rules need explicit tests regardless of the percentage. Never raise coverage by testing getters.
|
|
31
|
+
|
|
32
|
+
## Regression
|
|
33
|
+
Every material defect gets a test that fails before the fix and passes after. Reference the defect ID in the test name.
|
|
34
|
+
|
|
35
|
+
## Release blockers
|
|
36
|
+
Do not release with failing critical tests, failing security tests, a failing type check, a failing production build, failing critical E2E, unverified migrations, or unresolved critical vulnerabilities.
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: traceability-audit
|
|
3
|
+
description: Audit a project for missing features, disconnected controls, orphan endpoints, placeholders and false completion claims, and keep the feature registry accurate. Use this before declaring any feature or project complete, when asked "is this done" or "what is left", when taking over an unfamiliar project, and whenever the feature registry may be stale. Run it before any release decision.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Traceability and Completeness Audit
|
|
7
|
+
|
|
8
|
+
## The chain
|
|
9
|
+
REQ → FEATURE → WORKFLOW → UI → API → SERVICE → DATABASE → INTEGRATION → TEST → SECURITY TEST → EVIDENCE → RELEASE
|
|
10
|
+
|
|
11
|
+
Any missing link is a finding, not a formality.
|
|
12
|
+
|
|
13
|
+
## Run the mechanical audits first
|
|
14
|
+
```bash
|
|
15
|
+
.agent/scripts/placeholder-audit.sh # TODO/mock/placeholder/dead links in production paths
|
|
16
|
+
node .agent/scripts/validate-registry.mjs # registry schema + status/evidence consistency
|
|
17
|
+
```
|
|
18
|
+
Paste real output into `.agent/audits/`. Do not summarise it as "clean" without the output.
|
|
19
|
+
|
|
20
|
+
## Orphan detection
|
|
21
|
+
Search for and list:
|
|
22
|
+
- requirements with no implementation
|
|
23
|
+
- features with no tests
|
|
24
|
+
- UI controls with no handler, or a handler that only sets local state
|
|
25
|
+
- frontend calls to endpoints that do not exist
|
|
26
|
+
- endpoints with no consumer
|
|
27
|
+
- database tables with no owning feature
|
|
28
|
+
- integrations with no failure handling
|
|
29
|
+
- tests asserting behaviour that no longer exists
|
|
30
|
+
- documentation describing behaviour that does not exist
|
|
31
|
+
- environment variables read but undocumented, or documented but unread
|
|
32
|
+
|
|
33
|
+
## Completeness dimensions
|
|
34
|
+
Functional · interaction · integration · security · data/state persistence · failure paths · operational (logs, metrics, alerts, recovery) · documentation.
|
|
35
|
+
|
|
36
|
+
## Registry hygiene
|
|
37
|
+
Every feature in `.agent/state/feature-registry.json` needs: id, title, criticality, status, requirements, acceptanceCriteria, tests, evidence. A `VERIFIED` or `PRODUCTION_READY` entry with an empty `evidence` array is a lie and the validator will fail it.
|
|
38
|
+
|
|
39
|
+
## Report format
|
|
40
|
+
```
|
|
41
|
+
## Findings
|
|
42
|
+
| Severity | Feature | Finding | Evidence |
|
|
43
|
+
## Registry corrections applied
|
|
44
|
+
## Blockers
|
|
45
|
+
```
|
|
46
|
+
Report honestly: implemented, tested, verified, blocked, incomplete. Never report complete while a critical journey is broken.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: verification-evidence
|
|
3
|
+
description: How to capture proof that a check actually ran, and how to write a verification record. Use this before claiming anything passed, when marking a feature VERIFIED, when the user asks for proof or test results, and after every test or build run. Load this instead of writing "tests pass" from memory.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Verification and Evidence
|
|
7
|
+
|
|
8
|
+
## Rule
|
|
9
|
+
A claim without recorded output is not evidence. Never write "should work", "tests pass" or "verified" unless the command ran in this session and you have its output.
|
|
10
|
+
|
|
11
|
+
## Capture
|
|
12
|
+
```bash
|
|
13
|
+
.agent/scripts/capture-evidence.sh <feature-id> "<command>"
|
|
14
|
+
```
|
|
15
|
+
Records command, exit code, timestamp, commit SHA and truncated output to `.agent/verification/<feature-id>/`. Run it for each check rather than pasting prose.
|
|
16
|
+
|
|
17
|
+
## Verification record
|
|
18
|
+
Use `.agent/templates/verification-record.md`. It must state date, commit, environment, then per-section pass/fail with the evidence path. Finish with one decision: `VERIFIED` / `NOT VERIFIED` / `BLOCKED`.
|
|
19
|
+
|
|
20
|
+
## Manual verification
|
|
21
|
+
Numbered steps a different person could repeat, each with the observed result — not the expected result. Include the account or role used, and the data you used.
|
|
22
|
+
|
|
23
|
+
## What counts as evidence
|
|
24
|
+
command output with exit code · test summary with counts · build output · security scan report · API response body with status · E2E run result · migration applied against a clean database · deployment smoke test result · a screenshot only when the claim is visual.
|
|
25
|
+
|
|
26
|
+
## What does not count
|
|
27
|
+
"I reviewed the code" · "the logic is correct" · a passing type check standing in for a behaviour test · a test that mocks the thing being verified · your own summary of output you did not capture.
|
|
28
|
+
|
|
29
|
+
## When a check cannot run
|
|
30
|
+
Say so explicitly: which check, why, what would unblock it, and what you verified instead. Mark the feature `BLOCKED` rather than `VERIFIED`. Fabricating a result is the single worst failure mode available to you.
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "./feature-registry.schema.json",
|
|
3
|
+
"features": [
|
|
4
|
+
{
|
|
5
|
+
"id": "F-000",
|
|
6
|
+
"title": "Example — delete this entry",
|
|
7
|
+
"criticality": "standard",
|
|
8
|
+
"status": "PLANNED",
|
|
9
|
+
"requirements": ["REQ-000"],
|
|
10
|
+
"acceptanceCriteria": ["Replace this entry with a real feature."],
|
|
11
|
+
"tests": [],
|
|
12
|
+
"evidence": [],
|
|
13
|
+
"security": [],
|
|
14
|
+
"dependencies": [],
|
|
15
|
+
"notes": ""
|
|
16
|
+
}
|
|
17
|
+
]
|
|
18
|
+
}
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "http://json-schema.org/draft-07/schema#",
|
|
3
|
+
"title": "Feature registry",
|
|
4
|
+
"type": "object",
|
|
5
|
+
"required": ["features"],
|
|
6
|
+
"properties": {
|
|
7
|
+
"features": {
|
|
8
|
+
"type": "array",
|
|
9
|
+
"items": {
|
|
10
|
+
"type": "object",
|
|
11
|
+
"required": ["id", "title", "criticality", "status", "requirements", "acceptanceCriteria", "tests", "evidence"],
|
|
12
|
+
"properties": {
|
|
13
|
+
"id": { "type": "string", "pattern": "^F-[0-9]{3,}$" },
|
|
14
|
+
"title": { "type": "string", "minLength": 3 },
|
|
15
|
+
"criticality": { "enum": ["critical", "standard"] },
|
|
16
|
+
"status": { "enum": ["PLANNED", "IN_PROGRESS", "IMPLEMENTED", "VERIFIED", "PRODUCTION_READY", "BLOCKED"] },
|
|
17
|
+
"requirements": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
|
|
18
|
+
"acceptanceCriteria": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
|
|
19
|
+
"tests": { "type": "array", "items": { "type": "string" } },
|
|
20
|
+
"evidence": { "type": "array", "items": { "type": "string" } },
|
|
21
|
+
"security": { "type": "array", "items": { "type": "string" } },
|
|
22
|
+
"dependencies": { "type": "array", "items": { "type": "string" } },
|
|
23
|
+
"notes": { "type": "string" }
|
|
24
|
+
},
|
|
25
|
+
"additionalProperties": false
|
|
26
|
+
}
|
|
27
|
+
}
|
|
28
|
+
}
|
|
29
|
+
}
|
package/templates/adr.md
ADDED
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# {{FEATURE-ID}} — {{TITLE}}
|
|
2
|
+
|
|
3
|
+
Status: DISCOVERED
|
|
4
|
+
|
|
5
|
+
Requirement IDs:
|
|
6
|
+
- REQ-...
|
|
7
|
+
|
|
8
|
+
Actors/Roles:
|
|
9
|
+
|
|
10
|
+
Preconditions:
|
|
11
|
+
|
|
12
|
+
Workflow:
|
|
13
|
+
|
|
14
|
+
UI:
|
|
15
|
+
|
|
16
|
+
API:
|
|
17
|
+
|
|
18
|
+
Services:
|
|
19
|
+
|
|
20
|
+
Database:
|
|
21
|
+
|
|
22
|
+
Integrations:
|
|
23
|
+
|
|
24
|
+
Permissions:
|
|
25
|
+
|
|
26
|
+
Security risks:
|
|
27
|
+
|
|
28
|
+
Failure states:
|
|
29
|
+
|
|
30
|
+
Acceptance criteria:
|
|
31
|
+
|
|
32
|
+
Tests:
|
|
33
|
+
|
|
34
|
+
Evidence:
|
|
35
|
+
|
|
36
|
+
Dependencies:
|
|
37
|
+
|
|
38
|
+
Known issues:
|
|
39
|
+
|
|
40
|
+
Last verified:
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Implementation Prompt — {{WORK_ITEM_ID}} — {{TITLE}}
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
## Skills consulted
|
|
6
|
+
|
|
7
|
+
## Repository inspected
|
|
8
|
+
|
|
9
|
+
## Existing behavior
|
|
10
|
+
|
|
11
|
+
## Decisions
|
|
12
|
+
|
|
13
|
+
## Assumptions
|
|
14
|
+
|
|
15
|
+
## Files expected to change
|
|
16
|
+
|
|
17
|
+
## Requirements
|
|
18
|
+
|
|
19
|
+
### {{REQ-ID}}
|
|
20
|
+
|
|
21
|
+
## Architecture impact
|
|
22
|
+
|
|
23
|
+
## Security requirements
|
|
24
|
+
|
|
25
|
+
## Data/API impact
|
|
26
|
+
|
|
27
|
+
## Acceptance criteria
|
|
28
|
+
|
|
29
|
+
- [ ] ...
|
|
30
|
+
|
|
31
|
+
## Automated checks
|
|
32
|
+
|
|
33
|
+
```text
|
|
34
|
+
{{commands}}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Manual verification
|
|
38
|
+
|
|
39
|
+
1. ...
|
|
40
|
+
2. ...
|
|
41
|
+
3. ...
|
|
42
|
+
|
|
43
|
+
## Failure-path tests
|
|
44
|
+
|
|
45
|
+
## Out of scope
|
|
46
|
+
|
|
47
|
+
## Approval
|
|
48
|
+
|
|
49
|
+
- [ ] Approved
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Incident {{ID}}
|
|
2
|
+
|
|
3
|
+
Severity:
|
|
4
|
+
|
|
5
|
+
Date:
|
|
6
|
+
|
|
7
|
+
## Summary
|
|
8
|
+
|
|
9
|
+
## Impact
|
|
10
|
+
|
|
11
|
+
## Timeline
|
|
12
|
+
|
|
13
|
+
## Detection
|
|
14
|
+
|
|
15
|
+
## Containment
|
|
16
|
+
|
|
17
|
+
## Root cause
|
|
18
|
+
|
|
19
|
+
## Contributing factors
|
|
20
|
+
|
|
21
|
+
## Recovery
|
|
22
|
+
|
|
23
|
+
## Verification
|
|
24
|
+
|
|
25
|
+
## Corrective actions
|
|
26
|
+
|
|
27
|
+
## Preventive tests
|
|
28
|
+
|
|
29
|
+
## Owner
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Verification — {{FEATURE-ID}}
|
|
2
|
+
|
|
3
|
+
Date:
|
|
4
|
+
Commit:
|
|
5
|
+
Environment:
|
|
6
|
+
|
|
7
|
+
## Requirements
|
|
8
|
+
- [ ] Requirement satisfied
|
|
9
|
+
|
|
10
|
+
## Functional
|
|
11
|
+
- [ ] Happy path
|
|
12
|
+
- [ ] Failure paths
|
|
13
|
+
- [ ] Edge cases
|
|
14
|
+
|
|
15
|
+
## Security
|
|
16
|
+
- [ ] Authentication
|
|
17
|
+
- [ ] Authorization
|
|
18
|
+
- [ ] Abuse cases
|
|
19
|
+
|
|
20
|
+
## Integration
|
|
21
|
+
- [ ] API
|
|
22
|
+
- [ ] Database
|
|
23
|
+
- [ ] External dependencies
|
|
24
|
+
|
|
25
|
+
## Automated checks
|
|
26
|
+
|
|
27
|
+
Command:
|
|
28
|
+
Result:
|
|
29
|
+
|
|
30
|
+
Command:
|
|
31
|
+
Result:
|
|
32
|
+
|
|
33
|
+
## Manual tests
|
|
34
|
+
|
|
35
|
+
1.
|
|
36
|
+
2.
|
|
37
|
+
3.
|
|
38
|
+
|
|
39
|
+
## Evidence
|
|
40
|
+
|
|
41
|
+
## Remaining issues
|
|
42
|
+
|
|
43
|
+
## Decision
|
|
44
|
+
|
|
45
|
+
VERIFIED / NOT VERIFIED / BLOCKED
|