@fractary/core 0.7.24 → 0.7.25
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/dist/docs/type-registry.d.ts.map +1 -1
- package/dist/docs/type-registry.js +4 -5
- package/dist/docs/type-registry.js.map +1 -1
- package/dist/logs/type-registry.d.ts.map +1 -1
- package/dist/logs/type-registry.js +4 -5
- package/dist/logs/type-registry.js.map +1 -1
- package/package.json +4 -2
- package/templates/docs/adr/standards.md +29 -0
- package/templates/docs/adr/template.md +48 -0
- package/templates/docs/adr/type.yaml +74 -0
- package/templates/docs/api/standards.md +16 -0
- package/templates/docs/api/template.md +62 -0
- package/templates/docs/api/type.yaml +63 -0
- package/templates/docs/architecture/standards.md +15 -0
- package/templates/docs/architecture/template.md +58 -0
- package/templates/docs/architecture/type.yaml +63 -0
- package/templates/docs/audit/standards.md +15 -0
- package/templates/docs/audit/template.md +52 -0
- package/templates/docs/audit/type.yaml +61 -0
- package/templates/docs/changelog/standards.md +15 -0
- package/templates/docs/changelog/template.md +53 -0
- package/templates/docs/changelog/type.yaml +45 -0
- package/templates/docs/dataset/standards.md +15 -0
- package/templates/docs/dataset/template.md +65 -0
- package/templates/docs/dataset/type.yaml +63 -0
- package/templates/docs/etl/standards.md +15 -0
- package/templates/docs/etl/template.md +77 -0
- package/templates/docs/etl/type.yaml +66 -0
- package/templates/docs/guides/standards.md +16 -0
- package/templates/docs/guides/template.md +58 -0
- package/templates/docs/guides/type.yaml +61 -0
- package/templates/docs/infrastructure/standards.md +15 -0
- package/templates/docs/infrastructure/template.md +90 -0
- package/templates/docs/infrastructure/type.yaml +66 -0
- package/templates/docs/manifest.yaml +114 -0
- package/templates/docs/spec-api/standards.md +53 -0
- package/templates/docs/spec-api/template.md +96 -0
- package/templates/docs/spec-api/type.yaml +102 -0
- package/templates/docs/spec-basic/standards.md +24 -0
- package/templates/docs/spec-basic/template.md +51 -0
- package/templates/docs/spec-basic/type.yaml +92 -0
- package/templates/docs/spec-bug/standards.md +46 -0
- package/templates/docs/spec-bug/template.md +66 -0
- package/templates/docs/spec-bug/type.yaml +96 -0
- package/templates/docs/spec-feature/standards.md +53 -0
- package/templates/docs/spec-feature/template.md +105 -0
- package/templates/docs/spec-feature/type.yaml +106 -0
- package/templates/docs/spec-infrastructure/standards.md +58 -0
- package/templates/docs/spec-infrastructure/template.md +71 -0
- package/templates/docs/spec-infrastructure/type.yaml +102 -0
- package/templates/docs/standards/standards.md +15 -0
- package/templates/docs/standards/template.md +54 -0
- package/templates/docs/standards/type.yaml +61 -0
- package/templates/docs/testing/standards.md +15 -0
- package/templates/docs/testing/template.md +87 -0
- package/templates/docs/testing/type.yaml +65 -0
- package/templates/logs/audit/standards.md +33 -0
- package/templates/logs/audit/template.md +65 -0
- package/templates/logs/audit/type.yaml +85 -0
- package/templates/logs/build/standards.md +32 -0
- package/templates/logs/build/template.md +78 -0
- package/templates/logs/build/type.yaml +71 -0
- package/templates/logs/changelog/standards.md +34 -0
- package/templates/logs/changelog/template.md +71 -0
- package/templates/logs/changelog/type.yaml +70 -0
- package/templates/logs/debug/standards.md +33 -0
- package/templates/logs/debug/template.md +63 -0
- package/templates/logs/debug/type.yaml +77 -0
- package/templates/logs/deployment/standards.md +34 -0
- package/templates/logs/deployment/template.md +64 -0
- package/templates/logs/deployment/type.yaml +76 -0
- package/templates/logs/manifest.yaml +70 -0
- package/templates/logs/operational/standards.md +34 -0
- package/templates/logs/operational/template.md +71 -0
- package/templates/logs/operational/type.yaml +87 -0
- package/templates/logs/session/standards.md +34 -0
- package/templates/logs/session/template.md +81 -0
- package/templates/logs/session/type.yaml +69 -0
- package/templates/logs/test/standards.md +34 -0
- package/templates/logs/test/template.md +83 -0
- package/templates/logs/test/type.yaml +75 -0
- package/templates/logs/workflow/standards.md +35 -0
- package/templates/logs/workflow/template.md +95 -0
- package/templates/logs/workflow/type.yaml +91 -0
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Bug Fix Specification Standards
|
|
2
|
+
|
|
3
|
+
## Required Conventions
|
|
4
|
+
|
|
5
|
+
### 1. Bug Description
|
|
6
|
+
- ALWAYS describe the bug clearly and its user-facing impact
|
|
7
|
+
- Include severity/priority context if known
|
|
8
|
+
- Reference the original bug report or issue number
|
|
9
|
+
|
|
10
|
+
### 2. Steps to Reproduce
|
|
11
|
+
- ALWAYS provide numbered steps that reliably reproduce the bug
|
|
12
|
+
- ALWAYS include "Expected" and "Actual" behavior
|
|
13
|
+
- Include environment details if relevant (OS, browser, version)
|
|
14
|
+
|
|
15
|
+
### 3. Proposed Solution
|
|
16
|
+
- ALWAYS describe the fix approach before implementing
|
|
17
|
+
- Explain why this approach was chosen over alternatives
|
|
18
|
+
- Identify any trade-offs or limitations of the fix
|
|
19
|
+
|
|
20
|
+
### 4. Affected Areas
|
|
21
|
+
- ALWAYS list all components, files, or systems affected by the bug
|
|
22
|
+
- Include both directly affected and potentially impacted areas
|
|
23
|
+
- This helps identify regression testing scope
|
|
24
|
+
|
|
25
|
+
### 5. Testing
|
|
26
|
+
- ALWAYS include regression tests that verify the fix
|
|
27
|
+
- ALWAYS include edge case tests for related scenarios
|
|
28
|
+
- Tests should prevent the same bug from recurring
|
|
29
|
+
|
|
30
|
+
## Optional Section Guidelines
|
|
31
|
+
|
|
32
|
+
### Root Cause Analysis
|
|
33
|
+
- Include when the root cause is non-obvious
|
|
34
|
+
- Document the investigation process for future reference
|
|
35
|
+
- Identify systemic issues that may need broader fixes
|
|
36
|
+
|
|
37
|
+
### Regression Risk
|
|
38
|
+
- Include for fixes that touch critical code paths
|
|
39
|
+
- Document which existing functionality might be affected
|
|
40
|
+
- Specify additional testing needed beyond standard regression
|
|
41
|
+
|
|
42
|
+
## Best Practices
|
|
43
|
+
|
|
44
|
+
- Start with reproduction before proposing a fix
|
|
45
|
+
- Keep the spec focused on the specific bug — broader improvements belong in a separate spec
|
|
46
|
+
- Update root cause analysis as understanding evolves during investigation
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "{{title}}"
|
|
3
|
+
fractary_doc_type: spec-bug
|
|
4
|
+
status: {{status}}
|
|
5
|
+
date: {{date}}
|
|
6
|
+
{{#work_id}}
|
|
7
|
+
work_id: "{{work_id}}"
|
|
8
|
+
{{/work_id}}
|
|
9
|
+
{{#work_type}}
|
|
10
|
+
work_type: {{work_type}}
|
|
11
|
+
{{/work_type}}
|
|
12
|
+
source: {{source}}
|
|
13
|
+
validation_status: not_validated
|
|
14
|
+
tags: []
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# {{title}}
|
|
18
|
+
|
|
19
|
+
## Bug Description
|
|
20
|
+
|
|
21
|
+
{{description}}
|
|
22
|
+
|
|
23
|
+
## Steps to Reproduce
|
|
24
|
+
|
|
25
|
+
1. {{#steps}}{{.}}
|
|
26
|
+
{{/steps}}
|
|
27
|
+
|
|
28
|
+
**Expected:** {{expected}}
|
|
29
|
+
|
|
30
|
+
**Actual:** {{actual}}
|
|
31
|
+
|
|
32
|
+
{{#root_cause}}
|
|
33
|
+
## Root Cause Analysis
|
|
34
|
+
|
|
35
|
+
{{root_cause}}
|
|
36
|
+
{{/root_cause}}
|
|
37
|
+
|
|
38
|
+
## Proposed Solution
|
|
39
|
+
|
|
40
|
+
{{solution}}
|
|
41
|
+
|
|
42
|
+
## Affected Areas
|
|
43
|
+
|
|
44
|
+
{{#affected_areas}}
|
|
45
|
+
- {{.}}
|
|
46
|
+
{{/affected_areas}}
|
|
47
|
+
|
|
48
|
+
## Testing
|
|
49
|
+
|
|
50
|
+
### Regression Tests
|
|
51
|
+
|
|
52
|
+
{{#regression_tests}}
|
|
53
|
+
- [ ] {{.}}
|
|
54
|
+
{{/regression_tests}}
|
|
55
|
+
|
|
56
|
+
### Edge Case Tests
|
|
57
|
+
|
|
58
|
+
{{#edge_case_tests}}
|
|
59
|
+
- [ ] {{.}}
|
|
60
|
+
{{/edge_case_tests}}
|
|
61
|
+
|
|
62
|
+
{{#regression_risk}}
|
|
63
|
+
## Regression Risk
|
|
64
|
+
|
|
65
|
+
{{regression_risk}}
|
|
66
|
+
{{/regression_risk}}
|
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
id: spec-bug
|
|
2
|
+
display_name: Bug Fix Specification
|
|
3
|
+
description: Specification for bug investigation and fix
|
|
4
|
+
|
|
5
|
+
output_path: specs
|
|
6
|
+
|
|
7
|
+
file_naming:
|
|
8
|
+
pattern: "WORK-{work_id}-{slug}.md"
|
|
9
|
+
auto_number: false
|
|
10
|
+
slug_source: title
|
|
11
|
+
slug_max_length: 50
|
|
12
|
+
|
|
13
|
+
frontmatter:
|
|
14
|
+
required_fields:
|
|
15
|
+
- title
|
|
16
|
+
- fractary_doc_type
|
|
17
|
+
- status
|
|
18
|
+
- date
|
|
19
|
+
optional_fields:
|
|
20
|
+
- work_id
|
|
21
|
+
- work_type
|
|
22
|
+
- source
|
|
23
|
+
- validation_status
|
|
24
|
+
- tags
|
|
25
|
+
- author
|
|
26
|
+
- related
|
|
27
|
+
- changelog
|
|
28
|
+
defaults:
|
|
29
|
+
fractary_doc_type: spec-bug
|
|
30
|
+
status: draft
|
|
31
|
+
source: conversation
|
|
32
|
+
validation_status: not_validated
|
|
33
|
+
|
|
34
|
+
structure:
|
|
35
|
+
required_sections:
|
|
36
|
+
- Bug Description
|
|
37
|
+
- Steps to Reproduce
|
|
38
|
+
- Proposed Solution
|
|
39
|
+
- Affected Areas
|
|
40
|
+
- Testing
|
|
41
|
+
optional_sections:
|
|
42
|
+
- Root Cause Analysis
|
|
43
|
+
- Regression Risk
|
|
44
|
+
- References
|
|
45
|
+
section_order:
|
|
46
|
+
- Bug Description
|
|
47
|
+
- Steps to Reproduce
|
|
48
|
+
- Root Cause Analysis
|
|
49
|
+
- Proposed Solution
|
|
50
|
+
- Affected Areas
|
|
51
|
+
- Testing
|
|
52
|
+
- Regression Risk
|
|
53
|
+
- References
|
|
54
|
+
|
|
55
|
+
status:
|
|
56
|
+
allowed_values:
|
|
57
|
+
- draft
|
|
58
|
+
- review
|
|
59
|
+
- approved
|
|
60
|
+
- in-progress
|
|
61
|
+
- completed
|
|
62
|
+
- archived
|
|
63
|
+
default: draft
|
|
64
|
+
|
|
65
|
+
index_config:
|
|
66
|
+
index_file: specs/README.md
|
|
67
|
+
sort_by: date
|
|
68
|
+
sort_order: desc
|
|
69
|
+
entry_template: "- [**{{work_id}}**: {{title}}]({{relative_path}}) — {{status}}"
|
|
70
|
+
|
|
71
|
+
archive:
|
|
72
|
+
enabled: true
|
|
73
|
+
source: archive
|
|
74
|
+
trigger: on_status_change
|
|
75
|
+
trigger_statuses:
|
|
76
|
+
- archived
|
|
77
|
+
verify_checksum: true
|
|
78
|
+
delete_original: true
|
|
79
|
+
|
|
80
|
+
work_linking:
|
|
81
|
+
enabled: true
|
|
82
|
+
comment_on_create: true
|
|
83
|
+
comment_on_archive: true
|
|
84
|
+
require_closed_for_archive: true
|
|
85
|
+
|
|
86
|
+
refinement:
|
|
87
|
+
enabled: true
|
|
88
|
+
post_questions_to_work_item: true
|
|
89
|
+
maintain_changelog: true
|
|
90
|
+
|
|
91
|
+
fulfillment:
|
|
92
|
+
enabled: true
|
|
93
|
+
check_acceptance_criteria: true
|
|
94
|
+
check_files_modified: true
|
|
95
|
+
check_tests_added: true
|
|
96
|
+
check_docs_updated: false
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# Feature Specification Standards
|
|
2
|
+
|
|
3
|
+
## Required Conventions
|
|
4
|
+
|
|
5
|
+
### 1. Overview
|
|
6
|
+
- ALWAYS provide a clear, concise summary of the feature and its value
|
|
7
|
+
- ALWAYS explain why this feature is needed (business context)
|
|
8
|
+
- NEVER leave the overview as a placeholder
|
|
9
|
+
|
|
10
|
+
### 2. User Stories
|
|
11
|
+
- ALWAYS write user stories in "As a [role], I want [goal] so that [benefit]" format
|
|
12
|
+
- ALWAYS include at least one user story
|
|
13
|
+
- Each story should represent a distinct use case
|
|
14
|
+
|
|
15
|
+
### 3. Requirements
|
|
16
|
+
- ALWAYS separate functional and non-functional requirements
|
|
17
|
+
- ALWAYS write requirements as checkable items (- [ ] format)
|
|
18
|
+
- Requirements should be specific, measurable, and testable
|
|
19
|
+
- NEVER use vague language ("should be fast", "must be good")
|
|
20
|
+
|
|
21
|
+
### 4. Acceptance Criteria
|
|
22
|
+
- ALWAYS write acceptance criteria as verifiable checkboxes
|
|
23
|
+
- Each criterion should be independently testable
|
|
24
|
+
- Include both happy path and error scenarios
|
|
25
|
+
- NEVER duplicate requirements as acceptance criteria verbatim
|
|
26
|
+
|
|
27
|
+
### 5. Testing Strategy
|
|
28
|
+
- ALWAYS specify test types (unit, integration, e2e)
|
|
29
|
+
- ALWAYS include specific test scenarios, not just categories
|
|
30
|
+
- Testing should cover all acceptance criteria
|
|
31
|
+
|
|
32
|
+
## Optional Section Guidelines
|
|
33
|
+
|
|
34
|
+
### Technical Design
|
|
35
|
+
- Include when the implementation approach is non-obvious
|
|
36
|
+
- Document key architectural decisions and trade-offs
|
|
37
|
+
- Reference existing patterns in the codebase
|
|
38
|
+
|
|
39
|
+
### API Changes
|
|
40
|
+
- Document all new or modified endpoints
|
|
41
|
+
- Include request/response schemas
|
|
42
|
+
- Document error codes and edge cases
|
|
43
|
+
|
|
44
|
+
### Rollout Plan
|
|
45
|
+
- Include for features requiring phased deployment
|
|
46
|
+
- Document feature flags, migration steps, or rollback procedures
|
|
47
|
+
|
|
48
|
+
## Best Practices
|
|
49
|
+
|
|
50
|
+
- Keep specs focused on WHAT and WHY, not HOW (implementation details belong in code)
|
|
51
|
+
- Link related specs via the `related` frontmatter field
|
|
52
|
+
- Update the spec as understanding evolves (use the refinement changelog)
|
|
53
|
+
- Mark acceptance criteria as complete during implementation
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "{{title}}"
|
|
3
|
+
fractary_doc_type: spec-feature
|
|
4
|
+
status: {{status}}
|
|
5
|
+
date: {{date}}
|
|
6
|
+
{{#work_id}}
|
|
7
|
+
work_id: "{{work_id}}"
|
|
8
|
+
{{/work_id}}
|
|
9
|
+
{{#work_type}}
|
|
10
|
+
work_type: {{work_type}}
|
|
11
|
+
{{/work_type}}
|
|
12
|
+
source: {{source}}
|
|
13
|
+
validation_status: not_validated
|
|
14
|
+
tags: []
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# {{title}}
|
|
18
|
+
|
|
19
|
+
## Overview
|
|
20
|
+
|
|
21
|
+
{{overview}}
|
|
22
|
+
|
|
23
|
+
## User Stories
|
|
24
|
+
|
|
25
|
+
{{#user_stories}}
|
|
26
|
+
- As a {{role}}, I want {{goal}} so that {{benefit}}
|
|
27
|
+
{{/user_stories}}
|
|
28
|
+
|
|
29
|
+
## Requirements
|
|
30
|
+
|
|
31
|
+
### Functional
|
|
32
|
+
|
|
33
|
+
{{#functional_requirements}}
|
|
34
|
+
- [ ] {{.}}
|
|
35
|
+
{{/functional_requirements}}
|
|
36
|
+
|
|
37
|
+
### Non-Functional
|
|
38
|
+
|
|
39
|
+
{{#nonfunctional_requirements}}
|
|
40
|
+
- [ ] {{.}}
|
|
41
|
+
{{/nonfunctional_requirements}}
|
|
42
|
+
|
|
43
|
+
{{#technical_design}}
|
|
44
|
+
## Technical Design
|
|
45
|
+
|
|
46
|
+
{{technical_design}}
|
|
47
|
+
{{/technical_design}}
|
|
48
|
+
|
|
49
|
+
{{#api_changes}}
|
|
50
|
+
## API Changes
|
|
51
|
+
|
|
52
|
+
{{api_changes}}
|
|
53
|
+
{{/api_changes}}
|
|
54
|
+
|
|
55
|
+
{{#data_model}}
|
|
56
|
+
## Data Model
|
|
57
|
+
|
|
58
|
+
{{data_model}}
|
|
59
|
+
{{/data_model}}
|
|
60
|
+
|
|
61
|
+
## Acceptance Criteria
|
|
62
|
+
|
|
63
|
+
{{#acceptance_criteria}}
|
|
64
|
+
- [ ] {{.}}
|
|
65
|
+
{{/acceptance_criteria}}
|
|
66
|
+
|
|
67
|
+
## Testing Strategy
|
|
68
|
+
|
|
69
|
+
### Unit Tests
|
|
70
|
+
|
|
71
|
+
{{#unit_tests}}
|
|
72
|
+
- [ ] {{.}}
|
|
73
|
+
{{/unit_tests}}
|
|
74
|
+
|
|
75
|
+
### Integration Tests
|
|
76
|
+
|
|
77
|
+
{{#integration_tests}}
|
|
78
|
+
- [ ] {{.}}
|
|
79
|
+
{{/integration_tests}}
|
|
80
|
+
|
|
81
|
+
{{#security_considerations}}
|
|
82
|
+
## Security Considerations
|
|
83
|
+
|
|
84
|
+
{{security_considerations}}
|
|
85
|
+
{{/security_considerations}}
|
|
86
|
+
|
|
87
|
+
{{#performance_considerations}}
|
|
88
|
+
## Performance Considerations
|
|
89
|
+
|
|
90
|
+
{{performance_considerations}}
|
|
91
|
+
{{/performance_considerations}}
|
|
92
|
+
|
|
93
|
+
{{#rollout_plan}}
|
|
94
|
+
## Rollout Plan
|
|
95
|
+
|
|
96
|
+
{{rollout_plan}}
|
|
97
|
+
{{/rollout_plan}}
|
|
98
|
+
|
|
99
|
+
{{#open_questions}}
|
|
100
|
+
## Open Questions
|
|
101
|
+
|
|
102
|
+
{{#open_questions}}
|
|
103
|
+
- [ ] {{.}}
|
|
104
|
+
{{/open_questions}}
|
|
105
|
+
{{/open_questions}}
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
id: spec-feature
|
|
2
|
+
display_name: Feature Specification
|
|
3
|
+
description: Comprehensive specification for new feature development
|
|
4
|
+
|
|
5
|
+
output_path: specs
|
|
6
|
+
|
|
7
|
+
file_naming:
|
|
8
|
+
pattern: "WORK-{work_id}-{slug}.md"
|
|
9
|
+
auto_number: false
|
|
10
|
+
slug_source: title
|
|
11
|
+
slug_max_length: 50
|
|
12
|
+
|
|
13
|
+
frontmatter:
|
|
14
|
+
required_fields:
|
|
15
|
+
- title
|
|
16
|
+
- fractary_doc_type
|
|
17
|
+
- status
|
|
18
|
+
- date
|
|
19
|
+
optional_fields:
|
|
20
|
+
- work_id
|
|
21
|
+
- work_type
|
|
22
|
+
- source
|
|
23
|
+
- validation_status
|
|
24
|
+
- tags
|
|
25
|
+
- author
|
|
26
|
+
- related
|
|
27
|
+
- changelog
|
|
28
|
+
defaults:
|
|
29
|
+
fractary_doc_type: spec-feature
|
|
30
|
+
status: draft
|
|
31
|
+
source: conversation
|
|
32
|
+
validation_status: not_validated
|
|
33
|
+
|
|
34
|
+
structure:
|
|
35
|
+
required_sections:
|
|
36
|
+
- Overview
|
|
37
|
+
- User Stories
|
|
38
|
+
- Requirements
|
|
39
|
+
- Acceptance Criteria
|
|
40
|
+
- Testing Strategy
|
|
41
|
+
optional_sections:
|
|
42
|
+
- Technical Design
|
|
43
|
+
- API Changes
|
|
44
|
+
- Data Model
|
|
45
|
+
- Rollout Plan
|
|
46
|
+
- Security Considerations
|
|
47
|
+
- Performance Considerations
|
|
48
|
+
- Open Questions
|
|
49
|
+
- References
|
|
50
|
+
section_order:
|
|
51
|
+
- Overview
|
|
52
|
+
- User Stories
|
|
53
|
+
- Requirements
|
|
54
|
+
- Technical Design
|
|
55
|
+
- API Changes
|
|
56
|
+
- Data Model
|
|
57
|
+
- Acceptance Criteria
|
|
58
|
+
- Testing Strategy
|
|
59
|
+
- Security Considerations
|
|
60
|
+
- Performance Considerations
|
|
61
|
+
- Rollout Plan
|
|
62
|
+
- Open Questions
|
|
63
|
+
- References
|
|
64
|
+
|
|
65
|
+
status:
|
|
66
|
+
allowed_values:
|
|
67
|
+
- draft
|
|
68
|
+
- review
|
|
69
|
+
- approved
|
|
70
|
+
- in-progress
|
|
71
|
+
- completed
|
|
72
|
+
- archived
|
|
73
|
+
default: draft
|
|
74
|
+
|
|
75
|
+
index_config:
|
|
76
|
+
index_file: specs/README.md
|
|
77
|
+
sort_by: date
|
|
78
|
+
sort_order: desc
|
|
79
|
+
entry_template: "- [**{{work_id}}**: {{title}}]({{relative_path}}) — {{status}}"
|
|
80
|
+
|
|
81
|
+
archive:
|
|
82
|
+
enabled: true
|
|
83
|
+
source: archive
|
|
84
|
+
trigger: on_status_change
|
|
85
|
+
trigger_statuses:
|
|
86
|
+
- archived
|
|
87
|
+
verify_checksum: true
|
|
88
|
+
delete_original: true
|
|
89
|
+
|
|
90
|
+
work_linking:
|
|
91
|
+
enabled: true
|
|
92
|
+
comment_on_create: true
|
|
93
|
+
comment_on_archive: true
|
|
94
|
+
require_closed_for_archive: true
|
|
95
|
+
|
|
96
|
+
refinement:
|
|
97
|
+
enabled: true
|
|
98
|
+
post_questions_to_work_item: true
|
|
99
|
+
maintain_changelog: true
|
|
100
|
+
|
|
101
|
+
fulfillment:
|
|
102
|
+
enabled: true
|
|
103
|
+
check_acceptance_criteria: true
|
|
104
|
+
check_files_modified: true
|
|
105
|
+
check_tests_added: true
|
|
106
|
+
check_docs_updated: true
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# Infrastructure Specification Standards
|
|
2
|
+
|
|
3
|
+
## Required Conventions
|
|
4
|
+
|
|
5
|
+
### 1. Objective
|
|
6
|
+
- ALWAYS state the infrastructure change clearly and its motivation
|
|
7
|
+
- Include the expected outcome and success metrics
|
|
8
|
+
- Reference the triggering event (scaling need, incident, new service, etc.)
|
|
9
|
+
|
|
10
|
+
### 2. Current State
|
|
11
|
+
- ALWAYS document the existing infrastructure configuration
|
|
12
|
+
- Include relevant diagrams, resource counts, or architecture references
|
|
13
|
+
- Specify the baseline metrics (current capacity, cost, performance)
|
|
14
|
+
|
|
15
|
+
### 3. Proposed Changes
|
|
16
|
+
- ALWAYS write changes as checkable items (- [ ] format)
|
|
17
|
+
- Specify exact resources being added, modified, or removed
|
|
18
|
+
- Include configuration values (instance types, region, sizing, etc.)
|
|
19
|
+
|
|
20
|
+
### 4. Security Considerations
|
|
21
|
+
- ALWAYS document security implications of the change
|
|
22
|
+
- Address network access, IAM permissions, encryption, and secrets management
|
|
23
|
+
- Include any compliance requirements (SOC2, HIPAA, GDPR, etc.)
|
|
24
|
+
|
|
25
|
+
### 5. Rollback Plan
|
|
26
|
+
- ALWAYS document step-by-step rollback procedure
|
|
27
|
+
- Specify the rollback trigger criteria (what failure conditions warrant rollback)
|
|
28
|
+
- Include estimated rollback time
|
|
29
|
+
- NEVER deploy infrastructure changes without a rollback plan
|
|
30
|
+
|
|
31
|
+
### 6. Verification
|
|
32
|
+
- ALWAYS include verification steps as checkable items
|
|
33
|
+
- Include health checks, smoke tests, and monitoring confirmation
|
|
34
|
+
- Specify who needs to verify (ops team, security team, etc.)
|
|
35
|
+
|
|
36
|
+
## Optional Section Guidelines
|
|
37
|
+
|
|
38
|
+
### Monitoring & Alerts
|
|
39
|
+
- Include for any change that affects system observability
|
|
40
|
+
- Document new dashboards, alerts, or metrics
|
|
41
|
+
- Specify alert thresholds and escalation paths
|
|
42
|
+
|
|
43
|
+
### Cost Impact
|
|
44
|
+
- Include for changes that affect cloud spend
|
|
45
|
+
- Document expected monthly cost change (before → after)
|
|
46
|
+
- Include cost optimization considerations
|
|
47
|
+
|
|
48
|
+
### Capacity Planning
|
|
49
|
+
- Include for scaling-related changes
|
|
50
|
+
- Document expected growth and headroom
|
|
51
|
+
- Specify auto-scaling policies if applicable
|
|
52
|
+
|
|
53
|
+
## Best Practices
|
|
54
|
+
|
|
55
|
+
- Test infrastructure changes in a staging environment first
|
|
56
|
+
- Include terraform/IaC references when applicable
|
|
57
|
+
- Document the maintenance window if downtime is required
|
|
58
|
+
- Keep rollback plans tested and up to date
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "{{title}}"
|
|
3
|
+
fractary_doc_type: spec-infrastructure
|
|
4
|
+
status: {{status}}
|
|
5
|
+
date: {{date}}
|
|
6
|
+
{{#work_id}}
|
|
7
|
+
work_id: "{{work_id}}"
|
|
8
|
+
{{/work_id}}
|
|
9
|
+
{{#work_type}}
|
|
10
|
+
work_type: {{work_type}}
|
|
11
|
+
{{/work_type}}
|
|
12
|
+
source: {{source}}
|
|
13
|
+
validation_status: not_validated
|
|
14
|
+
tags: []
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# {{title}}
|
|
18
|
+
|
|
19
|
+
## Objective
|
|
20
|
+
|
|
21
|
+
{{objective}}
|
|
22
|
+
|
|
23
|
+
## Current State
|
|
24
|
+
|
|
25
|
+
{{current_state}}
|
|
26
|
+
|
|
27
|
+
## Proposed Changes
|
|
28
|
+
|
|
29
|
+
{{#changes}}
|
|
30
|
+
- [ ] {{.}}
|
|
31
|
+
{{/changes}}
|
|
32
|
+
|
|
33
|
+
## Security Considerations
|
|
34
|
+
|
|
35
|
+
{{security_considerations}}
|
|
36
|
+
|
|
37
|
+
{{#monitoring}}
|
|
38
|
+
## Monitoring & Alerts
|
|
39
|
+
|
|
40
|
+
{{monitoring}}
|
|
41
|
+
{{/monitoring}}
|
|
42
|
+
|
|
43
|
+
{{#capacity}}
|
|
44
|
+
## Capacity Planning
|
|
45
|
+
|
|
46
|
+
{{capacity}}
|
|
47
|
+
{{/capacity}}
|
|
48
|
+
|
|
49
|
+
{{#cost_impact}}
|
|
50
|
+
## Cost Impact
|
|
51
|
+
|
|
52
|
+
{{cost_impact}}
|
|
53
|
+
{{/cost_impact}}
|
|
54
|
+
|
|
55
|
+
## Rollback Plan
|
|
56
|
+
|
|
57
|
+
{{rollback_plan}}
|
|
58
|
+
|
|
59
|
+
## Verification
|
|
60
|
+
|
|
61
|
+
{{#verification_steps}}
|
|
62
|
+
- [ ] {{.}}
|
|
63
|
+
{{/verification_steps}}
|
|
64
|
+
|
|
65
|
+
{{#dependencies}}
|
|
66
|
+
## Dependencies
|
|
67
|
+
|
|
68
|
+
{{#dependencies}}
|
|
69
|
+
- {{.}}
|
|
70
|
+
{{/dependencies}}
|
|
71
|
+
{{/dependencies}}
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
id: spec-infrastructure
|
|
2
|
+
display_name: Infrastructure Specification
|
|
3
|
+
description: Specification for infrastructure and DevOps changes
|
|
4
|
+
|
|
5
|
+
output_path: specs
|
|
6
|
+
|
|
7
|
+
file_naming:
|
|
8
|
+
pattern: "WORK-{work_id}-{slug}.md"
|
|
9
|
+
auto_number: false
|
|
10
|
+
slug_source: title
|
|
11
|
+
slug_max_length: 50
|
|
12
|
+
|
|
13
|
+
frontmatter:
|
|
14
|
+
required_fields:
|
|
15
|
+
- title
|
|
16
|
+
- fractary_doc_type
|
|
17
|
+
- status
|
|
18
|
+
- date
|
|
19
|
+
optional_fields:
|
|
20
|
+
- work_id
|
|
21
|
+
- work_type
|
|
22
|
+
- source
|
|
23
|
+
- validation_status
|
|
24
|
+
- tags
|
|
25
|
+
- author
|
|
26
|
+
- related
|
|
27
|
+
- changelog
|
|
28
|
+
defaults:
|
|
29
|
+
fractary_doc_type: spec-infrastructure
|
|
30
|
+
status: draft
|
|
31
|
+
source: conversation
|
|
32
|
+
validation_status: not_validated
|
|
33
|
+
|
|
34
|
+
structure:
|
|
35
|
+
required_sections:
|
|
36
|
+
- Objective
|
|
37
|
+
- Current State
|
|
38
|
+
- Proposed Changes
|
|
39
|
+
- Security Considerations
|
|
40
|
+
- Rollback Plan
|
|
41
|
+
- Verification
|
|
42
|
+
optional_sections:
|
|
43
|
+
- Monitoring & Alerts
|
|
44
|
+
- Capacity Planning
|
|
45
|
+
- Cost Impact
|
|
46
|
+
- Dependencies
|
|
47
|
+
- References
|
|
48
|
+
section_order:
|
|
49
|
+
- Objective
|
|
50
|
+
- Current State
|
|
51
|
+
- Proposed Changes
|
|
52
|
+
- Security Considerations
|
|
53
|
+
- Monitoring & Alerts
|
|
54
|
+
- Capacity Planning
|
|
55
|
+
- Cost Impact
|
|
56
|
+
- Rollback Plan
|
|
57
|
+
- Verification
|
|
58
|
+
- Dependencies
|
|
59
|
+
- References
|
|
60
|
+
|
|
61
|
+
status:
|
|
62
|
+
allowed_values:
|
|
63
|
+
- draft
|
|
64
|
+
- review
|
|
65
|
+
- approved
|
|
66
|
+
- in-progress
|
|
67
|
+
- completed
|
|
68
|
+
- archived
|
|
69
|
+
default: draft
|
|
70
|
+
|
|
71
|
+
index_config:
|
|
72
|
+
index_file: specs/README.md
|
|
73
|
+
sort_by: date
|
|
74
|
+
sort_order: desc
|
|
75
|
+
entry_template: "- [**{{work_id}}**: {{title}}]({{relative_path}}) — {{status}}"
|
|
76
|
+
|
|
77
|
+
archive:
|
|
78
|
+
enabled: true
|
|
79
|
+
source: archive
|
|
80
|
+
trigger: on_status_change
|
|
81
|
+
trigger_statuses:
|
|
82
|
+
- archived
|
|
83
|
+
verify_checksum: true
|
|
84
|
+
delete_original: true
|
|
85
|
+
|
|
86
|
+
work_linking:
|
|
87
|
+
enabled: true
|
|
88
|
+
comment_on_create: true
|
|
89
|
+
comment_on_archive: true
|
|
90
|
+
require_closed_for_archive: true
|
|
91
|
+
|
|
92
|
+
refinement:
|
|
93
|
+
enabled: true
|
|
94
|
+
post_questions_to_work_item: true
|
|
95
|
+
maintain_changelog: true
|
|
96
|
+
|
|
97
|
+
fulfillment:
|
|
98
|
+
enabled: true
|
|
99
|
+
check_acceptance_criteria: false
|
|
100
|
+
check_files_modified: true
|
|
101
|
+
check_tests_added: false
|
|
102
|
+
check_docs_updated: true
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Standards Documentation Standards
|
|
2
|
+
|
|
3
|
+
## Required Conventions
|
|
4
|
+
|
|
5
|
+
- ALWAYS include clear scope
|
|
6
|
+
- ALWAYS provide examples
|
|
7
|
+
- ALWAYS document exceptions
|
|
8
|
+
- ALWAYS explain enforcement
|
|
9
|
+
|
|
10
|
+
## Best Practices
|
|
11
|
+
|
|
12
|
+
- Include good and bad examples
|
|
13
|
+
- Version standards documents
|
|
14
|
+
- Track changes in changelog
|
|
15
|
+
- Reference external standards
|