sdd-cli 0.1.2 → 0.1.4
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 +126 -89
- package/dist/cli.js +7 -3
- package/dist/commands/doctor.js +11 -2
- package/dist/commands/gen-architecture.js +13 -3
- package/dist/commands/gen-best-practices.js +12 -2
- package/dist/commands/gen-functional-spec.js +13 -3
- package/dist/commands/gen-project-readme.js +14 -4
- package/dist/commands/gen-technical-spec.js +13 -3
- package/dist/commands/gen-utils.js +9 -1
- package/dist/commands/hello.js +21 -3
- package/dist/commands/learn-deliver.js +17 -3
- package/dist/commands/learn-refine.js +32 -11
- package/dist/commands/learn-start.js +9 -2
- package/dist/commands/learn-utils.js +7 -4
- package/dist/commands/pr-audit.js +17 -3
- package/dist/commands/pr-finish.js +17 -3
- package/dist/commands/pr-report.js +17 -3
- package/dist/commands/pr-respond.js +17 -3
- package/dist/commands/pr-start.js +9 -2
- package/dist/commands/pr-utils.js +8 -5
- package/dist/commands/req-archive.js +14 -6
- package/dist/commands/req-create.js +71 -14
- package/dist/commands/req-export.js +11 -3
- package/dist/commands/req-finish.js +26 -11
- package/dist/commands/req-lint.js +10 -2
- package/dist/commands/req-list.js +10 -2
- package/dist/commands/req-plan.js +33 -11
- package/dist/commands/req-refine.js +54 -5
- package/dist/commands/req-report.js +10 -2
- package/dist/commands/req-start.js +29 -12
- package/dist/commands/req-status.js +10 -2
- package/dist/commands/test-plan.js +13 -5
- package/dist/context/flags.d.ts +2 -0
- package/dist/context/flags.js +5 -1
- package/dist/providers/codex.js +2 -2
- package/dist/router/prompt-map.js +17 -5
- package/dist/ui/prompt.d.ts +1 -0
- package/dist/ui/prompt.js +8 -0
- package/dist/validation/gates.d.ts +19 -0
- package/dist/validation/gates.js +41 -0
- package/dist/validation/validate.js +24 -4
- package/dist/workspace/index.d.ts +6 -0
- package/dist/workspace/index.js +41 -10
- package/flows/ADMISSIONS_ADMIN.md +35 -33
- package/flows/ART.md +35 -33
- package/flows/COURT_SYSTEM.md +35 -33
- package/flows/DATA_SCIENTIST.md +35 -33
- package/flows/ECOMMERCE.md +35 -33
- package/flows/ECONOMICS.md +35 -33
- package/flows/GRAPHIC_DESIGN.md +35 -33
- package/flows/HISTORY.md +35 -33
- package/flows/LAWYER.md +36 -34
- package/flows/PROGRAMMER.md +35 -33
- package/flows/RETAIL_STORE.md +35 -33
- package/flows/SOCIOLOGY.md +35 -33
- package/flows/STATE_ADMIN.md +35 -33
- package/flows/STUDENT_UNIVERSITY.md +35 -33
- package/flows/TAXES_ADMIN.md +35 -33
- package/flows/TEACHER.md +35 -33
- package/package.json +13 -3
- package/router/BUSINESS.flow.md +59 -57
- package/router/DATA_SCIENCE.flow.md +60 -58
- package/router/DESIGN.flow.md +60 -58
- package/router/HUMANITIES.flow.md +60 -58
- package/router/LEGAL.flow.md +60 -58
- package/router/SOFTWARE_FEATURE.flow.md +61 -59
package/flows/HISTORY.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: History research
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Produce a credible historical analysis with sources, timelines, and context.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What period or region is in scope?
|
|
8
|
-
- What is the research question or thesis?
|
|
9
|
-
- What depth is required (overview vs academic)?
|
|
10
|
-
- What sources are allowed or preferred?
|
|
11
|
-
- What format is required (essay, lecture, timeline)?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with scope and thesis
|
|
15
|
-
- `functional-spec.md` for narrative flow
|
|
16
|
-
- `technical-spec.md` for citation style and source rules
|
|
17
|
-
- `architecture.md` for section structure
|
|
18
|
-
- `test-plan.md` for source verification and bias checks
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Source bias and reliability
|
|
22
|
-
- Misinterpretation of primary sources
|
|
23
|
-
- Citation or attribution mistakes
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Claims are supported by sources.
|
|
27
|
-
- Timeline is consistent and verifiable.
|
|
28
|
-
- Multiple perspectives are represented.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Annotated bibliography
|
|
32
|
-
- Timeline map
|
|
33
|
-
- Thesis refinement log
|
|
1
|
+
# Flow: History research
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Produce a credible historical analysis with sources, timelines, and context.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What period or region is in scope?
|
|
8
|
+
- What is the research question or thesis?
|
|
9
|
+
- What depth is required (overview vs academic)?
|
|
10
|
+
- What sources are allowed or preferred?
|
|
11
|
+
- What format is required (essay, lecture, timeline)?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with scope and thesis
|
|
15
|
+
- `functional-spec.md` for narrative flow
|
|
16
|
+
- `technical-spec.md` for citation style and source rules
|
|
17
|
+
- `architecture.md` for section structure
|
|
18
|
+
- `test-plan.md` for source verification and bias checks
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Source bias and reliability
|
|
22
|
+
- Misinterpretation of primary sources
|
|
23
|
+
- Citation or attribution mistakes
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Claims are supported by sources.
|
|
27
|
+
- Timeline is consistent and verifiable.
|
|
28
|
+
- Multiple perspectives are represented.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Annotated bibliography
|
|
32
|
+
- Timeline map
|
|
33
|
+
- Thesis refinement log
|
|
34
|
+
|
|
35
|
+
|
package/flows/LAWYER.md
CHANGED
|
@@ -1,34 +1,36 @@
|
|
|
1
|
-
# Flow: Lawyer (legal practice)
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Build a system to manage cases, documents, deadlines, and client communication with strong audit trails.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What case types are supported (civil, criminal, corporate)?
|
|
8
|
-
- What jurisdictions and compliance rules apply?
|
|
9
|
-
- What data is sensitive or privileged?
|
|
10
|
-
- Who are the actors (partners, associates, paralegals, clients)?
|
|
11
|
-
- What are the legal deadlines and escalation rules?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with scope and compliance constraints
|
|
15
|
-
- `functional-spec.md` including case lifecycle and document review flows
|
|
16
|
-
- `technical-spec.md` detailing access control and audit logging
|
|
17
|
-
- `architecture.md` with secure storage and encryption at rest
|
|
18
|
-
- `test-plan.md` with permission boundary tests
|
|
19
|
-
- `decision-log/ADR-XXXX.md` for storage and retention choices
|
|
20
|
-
|
|
21
|
-
## Risk and compliance
|
|
22
|
-
- Data confidentiality (client privilege)
|
|
23
|
-
- Retention and legal hold policies
|
|
24
|
-
- Audit trails for all access and edits
|
|
25
|
-
|
|
26
|
-
## Acceptance criteria examples
|
|
27
|
-
- Every document access is logged with user, timestamp, and reason.
|
|
28
|
-
- Retention rules can be configured per case type.
|
|
29
|
-
- Access is role-based and least-privilege by default.
|
|
30
|
-
|
|
31
|
-
## Recommended outputs
|
|
32
|
-
- Secure storage and audit module
|
|
33
|
-
- Role-based access matrix
|
|
34
|
-
- Case timeline dashboard
|
|
1
|
+
# Flow: Lawyer (legal practice)
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Build a system to manage cases, documents, deadlines, and client communication with strong audit trails.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What case types are supported (civil, criminal, corporate)?
|
|
8
|
+
- What jurisdictions and compliance rules apply?
|
|
9
|
+
- What data is sensitive or privileged?
|
|
10
|
+
- Who are the actors (partners, associates, paralegals, clients)?
|
|
11
|
+
- What are the legal deadlines and escalation rules?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with scope and compliance constraints
|
|
15
|
+
- `functional-spec.md` including case lifecycle and document review flows
|
|
16
|
+
- `technical-spec.md` detailing access control and audit logging
|
|
17
|
+
- `architecture.md` with secure storage and encryption at rest
|
|
18
|
+
- `test-plan.md` with permission boundary tests
|
|
19
|
+
- `decision-log/ADR-XXXX.md` for storage and retention choices
|
|
20
|
+
|
|
21
|
+
## Risk and compliance
|
|
22
|
+
- Data confidentiality (client privilege)
|
|
23
|
+
- Retention and legal hold policies
|
|
24
|
+
- Audit trails for all access and edits
|
|
25
|
+
|
|
26
|
+
## Acceptance criteria examples
|
|
27
|
+
- Every document access is logged with user, timestamp, and reason.
|
|
28
|
+
- Retention rules can be configured per case type.
|
|
29
|
+
- Access is role-based and least-privilege by default.
|
|
30
|
+
|
|
31
|
+
## Recommended outputs
|
|
32
|
+
- Secure storage and audit module
|
|
33
|
+
- Role-based access matrix
|
|
34
|
+
- Case timeline dashboard
|
|
35
|
+
|
|
36
|
+
|
package/flows/PROGRAMMER.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: Programmer
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Implement a feature or system change with clean code, tests, and documentation.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What is the feature and who needs it?
|
|
8
|
-
- What are the acceptance criteria?
|
|
9
|
-
- What existing code areas are impacted?
|
|
10
|
-
- What constraints exist (performance, security, compatibility)?
|
|
11
|
-
- What is the expected rollout strategy?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with scope and constraints
|
|
15
|
-
- `functional-spec.md` for behavior and edge cases
|
|
16
|
-
- `technical-spec.md` for design and dependencies
|
|
17
|
-
- `architecture.md` for component-level impact
|
|
18
|
-
- `test-plan.md` for coverage and regression
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Regression risk on critical flows
|
|
22
|
-
- Backward compatibility
|
|
23
|
-
- Operational impacts
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Feature works in primary and edge scenarios.
|
|
27
|
-
- Tests cover new logic and critical regressions.
|
|
28
|
-
- Documentation updated for users and developers.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Implementation plan
|
|
32
|
-
- Code review checklist
|
|
33
|
-
- Rollout plan
|
|
1
|
+
# Flow: Programmer
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Implement a feature or system change with clean code, tests, and documentation.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What is the feature and who needs it?
|
|
8
|
+
- What are the acceptance criteria?
|
|
9
|
+
- What existing code areas are impacted?
|
|
10
|
+
- What constraints exist (performance, security, compatibility)?
|
|
11
|
+
- What is the expected rollout strategy?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with scope and constraints
|
|
15
|
+
- `functional-spec.md` for behavior and edge cases
|
|
16
|
+
- `technical-spec.md` for design and dependencies
|
|
17
|
+
- `architecture.md` for component-level impact
|
|
18
|
+
- `test-plan.md` for coverage and regression
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Regression risk on critical flows
|
|
22
|
+
- Backward compatibility
|
|
23
|
+
- Operational impacts
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Feature works in primary and edge scenarios.
|
|
27
|
+
- Tests cover new logic and critical regressions.
|
|
28
|
+
- Documentation updated for users and developers.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Implementation plan
|
|
32
|
+
- Code review checklist
|
|
33
|
+
- Rollout plan
|
|
34
|
+
|
|
35
|
+
|
package/flows/RETAIL_STORE.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: Retail store
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Support in-store sales, inventory, and customer management in a reliable, low-latency system.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What POS systems and devices are in scope?
|
|
8
|
-
- What inventory sources are authoritative?
|
|
9
|
-
- What promotions and discount rules exist?
|
|
10
|
-
- How should returns and exchanges work?
|
|
11
|
-
- What offline mode is required?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with store operations constraints
|
|
15
|
-
- `functional-spec.md` for POS, inventory, and staff flows
|
|
16
|
-
- `technical-spec.md` for device integration and offline sync
|
|
17
|
-
- `architecture.md` for store-local resiliency
|
|
18
|
-
- `test-plan.md` for offline/online transitions
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Inventory drift across locations
|
|
22
|
-
- Offline mode data loss
|
|
23
|
-
- PCI compliance for payments
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Store can operate for 8+ hours offline.
|
|
27
|
-
- Inventory reconciles within SLA after reconnect.
|
|
28
|
-
- Payment flows pass compliance checks.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- POS workflow diagram
|
|
32
|
-
- Offline sync strategy
|
|
33
|
-
- Store ops checklist
|
|
1
|
+
# Flow: Retail store
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Support in-store sales, inventory, and customer management in a reliable, low-latency system.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What POS systems and devices are in scope?
|
|
8
|
+
- What inventory sources are authoritative?
|
|
9
|
+
- What promotions and discount rules exist?
|
|
10
|
+
- How should returns and exchanges work?
|
|
11
|
+
- What offline mode is required?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with store operations constraints
|
|
15
|
+
- `functional-spec.md` for POS, inventory, and staff flows
|
|
16
|
+
- `technical-spec.md` for device integration and offline sync
|
|
17
|
+
- `architecture.md` for store-local resiliency
|
|
18
|
+
- `test-plan.md` for offline/online transitions
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Inventory drift across locations
|
|
22
|
+
- Offline mode data loss
|
|
23
|
+
- PCI compliance for payments
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Store can operate for 8+ hours offline.
|
|
27
|
+
- Inventory reconciles within SLA after reconnect.
|
|
28
|
+
- Payment flows pass compliance checks.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- POS workflow diagram
|
|
32
|
+
- Offline sync strategy
|
|
33
|
+
- Store ops checklist
|
|
34
|
+
|
|
35
|
+
|
package/flows/SOCIOLOGY.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: Sociology research
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Design a study or analysis of social behavior with clear methods and ethical safeguards.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What is the research question?
|
|
8
|
-
- What population or group is studied?
|
|
9
|
-
- What method is used (survey, interviews, observation)?
|
|
10
|
-
- What ethical requirements apply?
|
|
11
|
-
- What outcomes or hypotheses are tested?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with research scope
|
|
15
|
-
- `functional-spec.md` for research workflow
|
|
16
|
-
- `technical-spec.md` for data collection and analysis tools
|
|
17
|
-
- `architecture.md` for dataset and analysis pipeline
|
|
18
|
-
- `test-plan.md` for validity and bias checks
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Informed consent and privacy
|
|
22
|
-
- Sampling bias
|
|
23
|
-
- Misinterpretation of data
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Method aligns with research question.
|
|
27
|
-
- Data collection respects consent and privacy.
|
|
28
|
-
- Findings are reproducible and transparent.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Ethics checklist
|
|
32
|
-
- Survey or interview guide
|
|
33
|
-
- Data analysis plan
|
|
1
|
+
# Flow: Sociology research
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Design a study or analysis of social behavior with clear methods and ethical safeguards.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What is the research question?
|
|
8
|
+
- What population or group is studied?
|
|
9
|
+
- What method is used (survey, interviews, observation)?
|
|
10
|
+
- What ethical requirements apply?
|
|
11
|
+
- What outcomes or hypotheses are tested?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with research scope
|
|
15
|
+
- `functional-spec.md` for research workflow
|
|
16
|
+
- `technical-spec.md` for data collection and analysis tools
|
|
17
|
+
- `architecture.md` for dataset and analysis pipeline
|
|
18
|
+
- `test-plan.md` for validity and bias checks
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Informed consent and privacy
|
|
22
|
+
- Sampling bias
|
|
23
|
+
- Misinterpretation of data
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Method aligns with research question.
|
|
27
|
+
- Data collection respects consent and privacy.
|
|
28
|
+
- Findings are reproducible and transparent.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Ethics checklist
|
|
32
|
+
- Survey or interview guide
|
|
33
|
+
- Data analysis plan
|
|
34
|
+
|
|
35
|
+
|
package/flows/STATE_ADMIN.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: State administration
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Deliver reliable public services with strict compliance, transparency, and audit trails.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What service is being delivered (permits, benefits, licenses)?
|
|
8
|
-
- What laws and regulations apply?
|
|
9
|
-
- What are the SLA requirements for response times?
|
|
10
|
-
- Who are the actors (citizens, clerks, supervisors)?
|
|
11
|
-
- What data must be retained and for how long?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with legal constraints and SLA targets
|
|
15
|
-
- `functional-spec.md` for service request and approval flows
|
|
16
|
-
- `technical-spec.md` for identity and access management
|
|
17
|
-
- `architecture.md` for resiliency and data governance
|
|
18
|
-
- `test-plan.md` for SLA compliance and failure scenarios
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Legal compliance and transparency
|
|
22
|
-
- Accessibility for public services
|
|
23
|
-
- Disaster recovery requirements
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Requests are tracked end-to-end with timestamps.
|
|
27
|
-
- Service availability meets SLA targets.
|
|
28
|
-
- Decisions can be audited by authorized parties.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Citizen request tracking
|
|
32
|
-
- Compliance dashboard
|
|
33
|
-
- Audit-ready reports
|
|
1
|
+
# Flow: State administration
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Deliver reliable public services with strict compliance, transparency, and audit trails.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What service is being delivered (permits, benefits, licenses)?
|
|
8
|
+
- What laws and regulations apply?
|
|
9
|
+
- What are the SLA requirements for response times?
|
|
10
|
+
- Who are the actors (citizens, clerks, supervisors)?
|
|
11
|
+
- What data must be retained and for how long?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with legal constraints and SLA targets
|
|
15
|
+
- `functional-spec.md` for service request and approval flows
|
|
16
|
+
- `technical-spec.md` for identity and access management
|
|
17
|
+
- `architecture.md` for resiliency and data governance
|
|
18
|
+
- `test-plan.md` for SLA compliance and failure scenarios
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Legal compliance and transparency
|
|
22
|
+
- Accessibility for public services
|
|
23
|
+
- Disaster recovery requirements
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Requests are tracked end-to-end with timestamps.
|
|
27
|
+
- Service availability meets SLA targets.
|
|
28
|
+
- Decisions can be audited by authorized parties.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Citizen request tracking
|
|
32
|
+
- Compliance dashboard
|
|
33
|
+
- Audit-ready reports
|
|
34
|
+
|
|
35
|
+
|
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: Student (university)
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Plan and deliver a project or research task with clear milestones, requirements, and documentation.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What is the course or program requirement?
|
|
8
|
-
- What is the deliverable format (report, prototype, presentation)?
|
|
9
|
-
- What is the grading rubric or success criteria?
|
|
10
|
-
- What is the timeline and milestones?
|
|
11
|
-
- Who are the stakeholders (advisor, team members)?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with assignment constraints
|
|
15
|
-
- `functional-spec.md` for user stories or research tasks
|
|
16
|
-
- `technical-spec.md` for tools and stack
|
|
17
|
-
- `architecture.md` for system or study design
|
|
18
|
-
- `test-plan.md` or validation plan
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Plagiarism rules and citation requirements
|
|
22
|
-
- Data privacy for any collected data
|
|
23
|
-
- Academic integrity constraints
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Deliverable meets rubric and formatting rules.
|
|
27
|
-
- All claims are supported with citations.
|
|
28
|
-
- Prototype demonstrates required functionality.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Milestone plan
|
|
32
|
-
- Research log
|
|
33
|
-
- Final submission checklist
|
|
1
|
+
# Flow: Student (university)
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Plan and deliver a project or research task with clear milestones, requirements, and documentation.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What is the course or program requirement?
|
|
8
|
+
- What is the deliverable format (report, prototype, presentation)?
|
|
9
|
+
- What is the grading rubric or success criteria?
|
|
10
|
+
- What is the timeline and milestones?
|
|
11
|
+
- Who are the stakeholders (advisor, team members)?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with assignment constraints
|
|
15
|
+
- `functional-spec.md` for user stories or research tasks
|
|
16
|
+
- `technical-spec.md` for tools and stack
|
|
17
|
+
- `architecture.md` for system or study design
|
|
18
|
+
- `test-plan.md` or validation plan
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Plagiarism rules and citation requirements
|
|
22
|
+
- Data privacy for any collected data
|
|
23
|
+
- Academic integrity constraints
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Deliverable meets rubric and formatting rules.
|
|
27
|
+
- All claims are supported with citations.
|
|
28
|
+
- Prototype demonstrates required functionality.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Milestone plan
|
|
32
|
+
- Research log
|
|
33
|
+
- Final submission checklist
|
|
34
|
+
|
|
35
|
+
|
package/flows/TAXES_ADMIN.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: Taxes administration
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Manage tax filing, validation, audits, and compliance with strong security and traceability.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What tax types are supported (income, sales, corporate)?
|
|
8
|
-
- What validation rules are mandatory?
|
|
9
|
-
- What are the filing deadlines and penalty rules?
|
|
10
|
-
- Who can access taxpayer data?
|
|
11
|
-
- What integrations exist (banking, identity, government systems)?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with compliance and validation constraints
|
|
15
|
-
- `functional-spec.md` for filing and audit workflows
|
|
16
|
-
- `technical-spec.md` covering encryption and access controls
|
|
17
|
-
- `architecture.md` with data segregation and audit trails
|
|
18
|
-
- `test-plan.md` for validation accuracy and security
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Sensitive financial data
|
|
22
|
-
- Regulatory compliance and auditability
|
|
23
|
-
- Fraud detection requirements
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- All filings are validated against latest rules.
|
|
27
|
-
- Every data access is logged and auditable.
|
|
28
|
-
- Audit workflows can be triggered and tracked.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Filing validation engine
|
|
32
|
-
- Audit case management
|
|
33
|
-
- Compliance reporting
|
|
1
|
+
# Flow: Taxes administration
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Manage tax filing, validation, audits, and compliance with strong security and traceability.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What tax types are supported (income, sales, corporate)?
|
|
8
|
+
- What validation rules are mandatory?
|
|
9
|
+
- What are the filing deadlines and penalty rules?
|
|
10
|
+
- Who can access taxpayer data?
|
|
11
|
+
- What integrations exist (banking, identity, government systems)?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with compliance and validation constraints
|
|
15
|
+
- `functional-spec.md` for filing and audit workflows
|
|
16
|
+
- `technical-spec.md` covering encryption and access controls
|
|
17
|
+
- `architecture.md` with data segregation and audit trails
|
|
18
|
+
- `test-plan.md` for validation accuracy and security
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Sensitive financial data
|
|
22
|
+
- Regulatory compliance and auditability
|
|
23
|
+
- Fraud detection requirements
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- All filings are validated against latest rules.
|
|
27
|
+
- Every data access is logged and auditable.
|
|
28
|
+
- Audit workflows can be triggered and tracked.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Filing validation engine
|
|
32
|
+
- Audit case management
|
|
33
|
+
- Compliance reporting
|
|
34
|
+
|
|
35
|
+
|
package/flows/TEACHER.md
CHANGED
|
@@ -1,33 +1,35 @@
|
|
|
1
|
-
# Flow: Teacher (education)
|
|
2
|
-
|
|
3
|
-
## Goal
|
|
4
|
-
Create a system for lesson planning, assessments, and feedback with clear learning outcomes.
|
|
5
|
-
|
|
6
|
-
## Discovery prompts
|
|
7
|
-
- What grade levels and subjects are supported?
|
|
8
|
-
- What is the grading model (rubrics, points, mastery)?
|
|
9
|
-
- How are students and guardians notified?
|
|
10
|
-
- Are there accessibility requirements?
|
|
11
|
-
- What data privacy rules apply to students?
|
|
12
|
-
|
|
13
|
-
## Required artifacts
|
|
14
|
-
- `requirement.md` with learning objectives and scope
|
|
15
|
-
- `functional-spec.md` covering lesson, assignment, and grading flows
|
|
16
|
-
- `technical-spec.md` for integrations (LMS, email, calendars)
|
|
17
|
-
- `architecture.md` for content storage and versioning
|
|
18
|
-
- `test-plan.md` with grading accuracy and accessibility checks
|
|
19
|
-
|
|
20
|
-
## Risk and compliance
|
|
21
|
-
- Student data privacy
|
|
22
|
-
- Accessibility standards
|
|
23
|
-
- Content versioning and auditability
|
|
24
|
-
|
|
25
|
-
## Acceptance criteria examples
|
|
26
|
-
- Teachers can reuse and version lessons.
|
|
27
|
-
- Students receive feedback within configured SLAs.
|
|
28
|
-
- Accessibility checks are enforced for uploaded content.
|
|
29
|
-
|
|
30
|
-
## Recommended outputs
|
|
31
|
-
- Lesson plan templates
|
|
32
|
-
- Grading rubric engine
|
|
33
|
-
- Student progress analytics
|
|
1
|
+
# Flow: Teacher (education)
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
Create a system for lesson planning, assessments, and feedback with clear learning outcomes.
|
|
5
|
+
|
|
6
|
+
## Discovery prompts
|
|
7
|
+
- What grade levels and subjects are supported?
|
|
8
|
+
- What is the grading model (rubrics, points, mastery)?
|
|
9
|
+
- How are students and guardians notified?
|
|
10
|
+
- Are there accessibility requirements?
|
|
11
|
+
- What data privacy rules apply to students?
|
|
12
|
+
|
|
13
|
+
## Required artifacts
|
|
14
|
+
- `requirement.md` with learning objectives and scope
|
|
15
|
+
- `functional-spec.md` covering lesson, assignment, and grading flows
|
|
16
|
+
- `technical-spec.md` for integrations (LMS, email, calendars)
|
|
17
|
+
- `architecture.md` for content storage and versioning
|
|
18
|
+
- `test-plan.md` with grading accuracy and accessibility checks
|
|
19
|
+
|
|
20
|
+
## Risk and compliance
|
|
21
|
+
- Student data privacy
|
|
22
|
+
- Accessibility standards
|
|
23
|
+
- Content versioning and auditability
|
|
24
|
+
|
|
25
|
+
## Acceptance criteria examples
|
|
26
|
+
- Teachers can reuse and version lessons.
|
|
27
|
+
- Students receive feedback within configured SLAs.
|
|
28
|
+
- Accessibility checks are enforced for uploaded content.
|
|
29
|
+
|
|
30
|
+
## Recommended outputs
|
|
31
|
+
- Lesson plan templates
|
|
32
|
+
- Grading rubric engine
|
|
33
|
+
- Student progress analytics
|
|
34
|
+
|
|
35
|
+
|
package/package.json
CHANGED
|
@@ -1,9 +1,17 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "sdd-cli",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.4",
|
|
4
4
|
"description": "SDD-first, AI-native CLI for end-to-end delivery.",
|
|
5
|
+
"homepage": "https://github.com/jdsalasca/sdd-tool#readme",
|
|
6
|
+
"repository": {
|
|
7
|
+
"type": "git",
|
|
8
|
+
"url": "git+https://github.com/jdsalasca/sdd-tool.git"
|
|
9
|
+
},
|
|
10
|
+
"bugs": {
|
|
11
|
+
"url": "https://github.com/jdsalasca/sdd-tool/issues"
|
|
12
|
+
},
|
|
5
13
|
"bin": {
|
|
6
|
-
"sdd-
|
|
14
|
+
"sdd-cli": "dist/cli.js",
|
|
7
15
|
"sdd": "dist/cli.js"
|
|
8
16
|
},
|
|
9
17
|
"main": "dist/cli.js",
|
|
@@ -18,7 +26,9 @@
|
|
|
18
26
|
"scripts": {
|
|
19
27
|
"build": "tsc -p tsconfig.json",
|
|
20
28
|
"start": "node dist/cli.js",
|
|
21
|
-
"dev": "ts-node src/cli.ts"
|
|
29
|
+
"dev": "ts-node src/cli.ts",
|
|
30
|
+
"pretest": "npm run build",
|
|
31
|
+
"test": "node --test tests/*.test.js"
|
|
22
32
|
},
|
|
23
33
|
"dependencies": {
|
|
24
34
|
"ajv": "^8.17.1",
|