Skip to content

Commit 0515822

Browse files
ArtifizerArtifizer
authored
Merge pull request #1 from aviator5/initial-version
Move dnaspec from personal git repo
2 parents bb8074a + 7225049 commit 0515822

158 files changed

Lines changed: 26954 additions & 0 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.agent/workflows/openspec-apply.md‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
---
2+
description: Implement an approved OpenSpec change and keep tasks in sync.
3+
---
4+
<!-- OPENSPEC:START -->
5+
**Guardrails**
6+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
7+
- Keep changes tightly scoped to the requested outcome.
8+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
9+
10+
**Steps**
11+
Track these steps as TODOs and complete them one by one.
12+
1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
13+
2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
14+
3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
15+
4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
16+
5. Reference `openspec list` or `openspec show <item>` when additional context is required.
17+
18+
**Reference**
19+
- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
20+
<!-- OPENSPEC:END -->

‎.agent/workflows/openspec-archive.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
---
2+
description: Archive a deployed OpenSpec change and update specs.
3+
---
4+
<!-- OPENSPEC:START -->
5+
**Guardrails**
6+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
7+
- Keep changes tightly scoped to the requested outcome.
8+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
9+
10+
**Steps**
11+
1. Determine the change ID to archive:
12+
- If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
13+
- If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
14+
- Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
15+
- If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
16+
2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
17+
3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
18+
4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
19+
5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
20+
21+
**Reference**
22+
- Use `openspec list` to confirm change IDs before archiving.
23+
- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
24+
<!-- OPENSPEC:END -->

‎.agent/workflows/openspec-proposal.md‎

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
---
2+
description: Scaffold a new OpenSpec change and validate strictly.
3+
---
4+
<!-- OPENSPEC:START -->
5+
**Guardrails**
6+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
7+
- Keep changes tightly scoped to the requested outcome.
8+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
9+
- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
10+
- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
11+
12+
**Steps**
13+
1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
14+
2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
15+
3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
16+
4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
17+
5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
18+
6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
19+
7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
20+
21+
**Reference**
22+
- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
23+
- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
24+
- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
25+
<!-- OPENSPEC:END -->

‎.claude/commands/openspec/apply.md‎

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
---
2+
name: OpenSpec: Apply
3+
description: Implement an approved OpenSpec change and keep tasks in sync.
4+
category: OpenSpec
5+
tags: [openspec, apply]
6+
---
7+
<!-- OPENSPEC:START -->
8+
**Guardrails**
9+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
10+
- Keep changes tightly scoped to the requested outcome.
11+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
12+
13+
**Steps**
14+
Track these steps as TODOs and complete them one by one.
15+
1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
16+
2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
17+
3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
18+
4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
19+
5. Reference `openspec list` or `openspec show <item>` when additional context is required.
20+
21+
**Reference**
22+
- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
23+
<!-- OPENSPEC:END -->

‎.claude/commands/openspec/archive.md‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
name: OpenSpec: Archive
3+
description: Archive a deployed OpenSpec change and update specs.
4+
category: OpenSpec
5+
tags: [openspec, archive]
6+
---
7+
<!-- OPENSPEC:START -->
8+
**Guardrails**
9+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
10+
- Keep changes tightly scoped to the requested outcome.
11+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
12+
13+
**Steps**
14+
1. Determine the change ID to archive:
15+
- If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
16+
- If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
17+
- Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
18+
- If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
19+
2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
20+
3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
21+
4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
22+
5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
23+
24+
**Reference**
25+
- Use `openspec list` to confirm change IDs before archiving.
26+
- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
27+
<!-- OPENSPEC:END -->

‎.claude/commands/openspec/proposal.md‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
name: OpenSpec: Proposal
3+
description: Scaffold a new OpenSpec change and validate strictly.
4+
category: OpenSpec
5+
tags: [openspec, change]
6+
---
7+
<!-- OPENSPEC:START -->
8+
**Guardrails**
9+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
10+
- Keep changes tightly scoped to the requested outcome.
11+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
12+
- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
13+
- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
14+
15+
**Steps**
16+
1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
17+
2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
18+
3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
19+
4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
20+
5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
21+
6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
22+
7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
23+
24+
**Reference**
25+
- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
26+
- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
27+
- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
28+
<!-- OPENSPEC:END -->

‎.github/prompts/openspec-apply.prompt.md‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
---
2+
description: Implement an approved OpenSpec change and keep tasks in sync.
3+
---
4+
5+
$ARGUMENTS
6+
<!-- OPENSPEC:START -->
7+
**Guardrails**
8+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
9+
- Keep changes tightly scoped to the requested outcome.
10+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
11+
12+
**Steps**
13+
Track these steps as TODOs and complete them one by one.
14+
1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
15+
2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
16+
3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
17+
4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
18+
5. Reference `openspec list` or `openspec show <item>` when additional context is required.
19+
20+
**Reference**
21+
- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
22+
<!-- OPENSPEC:END -->

‎.github/prompts/openspec-archive.prompt.md‎

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
---
2+
description: Archive a deployed OpenSpec change and update specs.
3+
---
4+
5+
$ARGUMENTS
6+
<!-- OPENSPEC:START -->
7+
**Guardrails**
8+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
9+
- Keep changes tightly scoped to the requested outcome.
10+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
11+
12+
**Steps**
13+
1. Determine the change ID to archive:
14+
- If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
15+
- If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
16+
- Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
17+
- If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
18+
2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
19+
3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
20+
4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
21+
5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
22+
23+
**Reference**
24+
- Use `openspec list` to confirm change IDs before archiving.
25+
- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
26+
<!-- OPENSPEC:END -->

‎.github/prompts/openspec-proposal.prompt.md‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
---
2+
description: Scaffold a new OpenSpec change and validate strictly.
3+
---
4+
5+
$ARGUMENTS
6+
<!-- OPENSPEC:START -->
7+
**Guardrails**
8+
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
9+
- Keep changes tightly scoped to the requested outcome.
10+
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
11+
- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
12+
- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
13+
14+
**Steps**
15+
1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
16+
2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
17+
3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
18+
4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
19+
5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
20+
6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
21+
7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
22+
23+
**Reference**
24+
- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
25+
- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
26+
- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
27+
<!-- OPENSPEC:END -->

‎.github/workflows/ci.yml‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
name: CI
2+
3+
on:
4+
push:
5+
branches: [ main ]
6+
pull_request:
7+
branches: [ main ]
8+
9+
jobs:
10+
test:
11+
name: Test
12+
runs-on: ubuntu-latest
13+
strategy:
14+
matrix:
15+
go-version: ['1.25']
16+
env:
17+
GOTOOLCHAIN: local
18+
19+
steps:
20+
- name: Checkout code
21+
uses: actions/checkout@v4
22+
23+
- name: Set up Go
24+
uses: actions/setup-go@v5
25+
with:
26+
go-version: ${{ matrix.go-version }}
27+
cache: true
28+
29+
- name: Download dependencies
30+
run: go mod download
31+
32+
- name: Run tests
33+
run: go test -race -v ./...
34+
35+
- name: Run tests with coverage
36+
run: go test -race -coverprofile=coverage.out -covermode=atomic ./...
37+
38+
- name: Upload coverage to Codecov
39+
uses: codecov/codecov-action@v4
40+
with:
41+
files: ./coverage.out
42+
flags: unittests
43+
name: codecov-umbrella
44+
env:
45+
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
46+
47+
lint:
48+
name: Lint
49+
runs-on: ubuntu-latest
50+
51+
steps:
52+
- name: Checkout code
53+
uses: actions/checkout@v4
54+
55+
- name: Set up Go
56+
uses: actions/setup-go@v5
57+
with:
58+
go-version: '1.25'
59+
cache: true
60+
61+
- name: Run golangci-lint
62+
uses: golangci/golangci-lint-action@v7
63+
with:
64+
version: v2.5.0
65+
args: --timeout=5m

0 commit comments

Comments
 (0)