@forwardimpact/pathway 0.3.0 → 0.5.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/app/commands/agent.js +1 -1
- package/app/commands/behaviour.js +1 -1
- package/app/commands/command-factory.js +2 -2
- package/app/commands/discipline.js +1 -1
- package/app/commands/driver.js +1 -1
- package/app/commands/grade.js +1 -1
- package/app/commands/index.js +4 -3
- package/app/commands/serve.js +2 -2
- package/app/commands/site.js +22 -2
- package/app/commands/skill.js +57 -3
- package/app/commands/stage.js +1 -1
- package/app/commands/tool.js +112 -0
- package/app/commands/track.js +1 -1
- package/app/components/card.js +11 -1
- package/app/components/checklist.js +6 -4
- package/app/components/code-display.js +153 -0
- package/app/components/markdown-textarea.js +153 -0
- package/app/css/bundles/app.css +14 -0
- package/app/css/components/badges.css +15 -8
- package/app/css/components/forms.css +55 -0
- package/app/css/components/layout.css +12 -0
- package/app/css/components/surfaces.css +71 -3
- package/app/css/components/typography.css +1 -2
- package/app/css/pages/agent-builder.css +11 -102
- package/app/css/pages/detail.css +60 -0
- package/app/css/pages/job-builder.css +0 -42
- package/app/css/tokens.css +3 -0
- package/app/formatters/agent/dom.js +26 -71
- package/app/formatters/agent/profile.js +67 -10
- package/app/formatters/agent/skill.js +48 -6
- package/app/formatters/grade/dom.js +6 -6
- package/app/formatters/job/description.js +21 -16
- package/app/formatters/job/dom.js +9 -70
- package/app/formatters/json-ld.js +1 -1
- package/app/formatters/shared.js +58 -0
- package/app/formatters/skill/dom.js +70 -3
- package/app/formatters/skill/markdown.js +18 -0
- package/app/formatters/skill/shared.js +14 -4
- package/app/formatters/stage/microdata.js +2 -2
- package/app/formatters/stage/shared.js +3 -3
- package/app/formatters/tool/shared.js +78 -0
- package/app/handout-main.js +19 -18
- package/app/index.html +16 -3
- package/app/lib/card-mappers.js +91 -17
- package/app/lib/render.js +4 -0
- package/app/lib/yaml-loader.js +12 -1
- package/app/main.js +4 -0
- package/app/model/agent.js +47 -23
- package/app/model/checklist.js +2 -2
- package/app/model/derivation.js +5 -5
- package/app/model/levels.js +4 -2
- package/app/model/loader.js +12 -1
- package/app/model/validation.js +77 -11
- package/app/pages/agent-builder.js +121 -77
- package/app/pages/landing.js +35 -15
- package/app/pages/self-assessment.js +7 -5
- package/app/pages/skill.js +5 -17
- package/app/pages/stage.js +12 -8
- package/app/pages/tool.js +50 -0
- package/app/slide-main.js +1 -1
- package/app/slides/chapter.js +8 -8
- package/app/slides/index.js +26 -26
- package/app/slides/overview.js +8 -8
- package/app/slides/skill.js +1 -0
- package/bin/pathway.js +31 -16
- package/examples/capabilities/business.yaml +18 -18
- package/examples/capabilities/delivery.yaml +54 -37
- package/examples/capabilities/people.yaml +1 -1
- package/examples/capabilities/reliability.yaml +130 -115
- package/examples/capabilities/scale.yaml +39 -37
- package/examples/disciplines/engineering_management.yaml +1 -1
- package/examples/framework.yaml +21 -9
- package/examples/grades.yaml +5 -7
- package/examples/self-assessments.yaml +1 -1
- package/examples/stages.yaml +18 -10
- package/package.json +2 -1
- package/templates/agent.template.md +47 -17
- package/templates/job.template.md +8 -8
- package/templates/skill.template.md +33 -11
- package/examples/agents/.claude/skills/architecture-design/SKILL.md +0 -130
- package/examples/agents/.claude/skills/cloud-platforms/SKILL.md +0 -131
- package/examples/agents/.claude/skills/code-quality-review/SKILL.md +0 -108
- package/examples/agents/.claude/skills/devops-cicd/SKILL.md +0 -142
- package/examples/agents/.claude/skills/full-stack-development/SKILL.md +0 -134
- package/examples/agents/.claude/skills/sre-practices/SKILL.md +0 -163
- package/examples/agents/.claude/skills/technical-debt-management/SKILL.md +0 -164
- package/examples/agents/.github/agents/se-platform-code.agent.md +0 -132
- package/examples/agents/.github/agents/se-platform-plan.agent.md +0 -131
- package/examples/agents/.github/agents/se-platform-review.agent.md +0 -136
- package/examples/agents/.vscode/settings.json +0 -8
package/examples/framework.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# yaml-language-server: $schema=https://schema.forwardimpact.team/json/framework.schema.json
|
|
2
2
|
|
|
3
3
|
title: Engineering Pathway
|
|
4
|
-
|
|
4
|
+
emojiIcon: "🧭"
|
|
5
5
|
tag: "#AcmeCorp"
|
|
6
6
|
description: |
|
|
7
7
|
A unified framework for human and AI collaboration in engineering. Define roles, track skills and behaviours, build career paths, and generate AI coding agents—all from the same coherent foundation. The pathway aligns human capabilities with AI assistance, enabling productive teams in the AI era.
|
|
@@ -10,48 +10,60 @@ description: |
|
|
|
10
10
|
entityDefinitions:
|
|
11
11
|
driver:
|
|
12
12
|
title: Drivers
|
|
13
|
-
|
|
13
|
+
emojiIcon: "🎯"
|
|
14
14
|
description: |
|
|
15
15
|
Organizational outcomes that productive teams achieve. Drivers link skills and behaviours to business value, helping teams understand how their capabilities contribute to organizational success.
|
|
16
16
|
|
|
17
17
|
skill:
|
|
18
18
|
title: Skills
|
|
19
|
-
|
|
19
|
+
emojiIcon: "💡"
|
|
20
20
|
description: |
|
|
21
21
|
Capabilities required to perform work effectively. Skills are organized by capability and measured across five levels from Awareness to Expert. They form the foundation of technical and professional competence.
|
|
22
22
|
|
|
23
23
|
behaviour:
|
|
24
24
|
title: Behaviours
|
|
25
|
-
|
|
25
|
+
emojiIcon: "🧠"
|
|
26
26
|
description: |
|
|
27
27
|
Mindsets and ways of working that underpin effective application of skills. Behaviours are measured across five maturity levels from Emerging to Exemplifying. They describe how engineers approach their work, collaborate with others, and drive outcomes.
|
|
28
28
|
|
|
29
29
|
discipline:
|
|
30
30
|
title: Disciplines
|
|
31
|
-
|
|
31
|
+
emojiIcon: "🔧"
|
|
32
32
|
description: |
|
|
33
33
|
Engineering specializations that define T-shaped skill profiles. Each discipline specifies primary skills for deep expertise, secondary skills for supporting capabilities, and broad skills for general awareness. Disciplines answer the question: "What kind of engineer are you?"
|
|
34
34
|
|
|
35
35
|
grade:
|
|
36
36
|
title: Grades
|
|
37
|
-
|
|
37
|
+
emojiIcon: "📊"
|
|
38
38
|
description: |
|
|
39
39
|
Career levels that define expectations for skill proficiency, behaviour maturity, and scope of impact. Grades provide a clear progression path from entry-level to distinguished leadership roles, with defined expectations at each stage.
|
|
40
40
|
|
|
41
41
|
track:
|
|
42
42
|
title: Tracks
|
|
43
|
-
|
|
43
|
+
emojiIcon: "🛤️"
|
|
44
44
|
description: |
|
|
45
45
|
Work contexts that modify skill and behaviour expectations based on the nature of the role. Tracks answer the question: "Where and how do you work?" They apply modifiers to adjust expectations for different working environments and responsibilities.
|
|
46
46
|
|
|
47
47
|
job:
|
|
48
48
|
title: Jobs
|
|
49
|
-
|
|
49
|
+
emojiIcon: "📋"
|
|
50
50
|
description: |
|
|
51
51
|
Complete role specifications that combine discipline, track, and grade into actionable job definitions with skill matrices, behaviour profiles, and derived responsibilities. Jobs represent the practical application of the framework to define concrete engineering positions.
|
|
52
52
|
|
|
53
53
|
agent:
|
|
54
54
|
title: Agents
|
|
55
|
-
|
|
55
|
+
emojiIcon: "🤖"
|
|
56
56
|
description: |
|
|
57
57
|
AI coding agent configurations generated from the same disciplines, tracks, and skills that define human roles. Agent profiles and skills follow the GitHub Copilot specification, ensuring AI assistants understand context, constraints, and working styles aligned with human engineering expectations.
|
|
58
|
+
|
|
59
|
+
stage:
|
|
60
|
+
title: Stages
|
|
61
|
+
emojiIcon: "🔄"
|
|
62
|
+
description: |
|
|
63
|
+
Defined phases of the engineering lifecycle that structure work from planning through delivery and review. Stages provide context for AI agents and define entry criteria, exit criteria, and appropriate handoffs between phases.
|
|
64
|
+
|
|
65
|
+
tool:
|
|
66
|
+
title: Tools
|
|
67
|
+
emojiIcon: "🔧"
|
|
68
|
+
description: |
|
|
69
|
+
Recommended tools and utilities referenced by skills for effective engineering workflows. Tools are linked to specific skills with guidance on when and how to use them, surfacing best practices directly in skill definitions.
|
package/examples/grades.yaml
CHANGED
|
@@ -82,10 +82,10 @@
|
|
|
82
82
|
breadthCriteria:
|
|
83
83
|
practitioner: 4
|
|
84
84
|
expectations:
|
|
85
|
-
impactScope: Multi-team initiatives with
|
|
85
|
+
impactScope: Multi-team initiatives with area-wide impact
|
|
86
86
|
autonomyExpectation: Set own direction within broader strategic goals
|
|
87
87
|
influenceScope:
|
|
88
|
-
Influence
|
|
88
|
+
Influence teams in your area and be recognized as a domain expert
|
|
89
89
|
complexityHandled:
|
|
90
90
|
Very high complexity driving through ambiguity to deliver results
|
|
91
91
|
|
|
@@ -107,11 +107,9 @@
|
|
|
107
107
|
practitioner: 5
|
|
108
108
|
expert: 2
|
|
109
109
|
expectations:
|
|
110
|
-
impactScope:
|
|
111
|
-
Organization-wide technical strategy and architectural direction
|
|
110
|
+
impactScope: Business unit technical strategy and architectural direction
|
|
112
111
|
autonomyExpectation:
|
|
113
112
|
Define strategic direction and be accountable for outcomes
|
|
114
113
|
influenceScope:
|
|
115
|
-
Shape
|
|
116
|
-
complexityHandled:
|
|
117
|
-
Organizational-scale complexity creating clarity from chaos
|
|
114
|
+
Shape practices across the business unit and maintain external visibility
|
|
115
|
+
complexityHandled: Business unit complexity creating clarity from ambiguity
|
package/examples/stages.yaml
CHANGED
|
@@ -2,9 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
- id: specify
|
|
4
4
|
name: Specify
|
|
5
|
-
|
|
5
|
+
emojiIcon: "🎯"
|
|
6
6
|
description:
|
|
7
|
-
|
|
7
|
+
Your primary task is to define WHAT users need and WHY, not how to build it.
|
|
8
|
+
Gather requirements, write user stories, and define acceptance criteria.
|
|
8
9
|
handoffs:
|
|
9
10
|
- targetStage: specify
|
|
10
11
|
label: Refine Spec
|
|
@@ -28,9 +29,10 @@
|
|
|
28
29
|
|
|
29
30
|
- id: plan
|
|
30
31
|
name: Plan
|
|
31
|
-
|
|
32
|
+
emojiIcon: "📐"
|
|
32
33
|
description:
|
|
33
|
-
|
|
34
|
+
Your primary task is to define HOW to build the solution. Make technology
|
|
35
|
+
choices, design architecture, define contracts and data models.
|
|
34
36
|
handoffs:
|
|
35
37
|
- targetStage: plan
|
|
36
38
|
label: Refine Plan
|
|
@@ -57,8 +59,10 @@
|
|
|
57
59
|
|
|
58
60
|
- id: code
|
|
59
61
|
name: Code
|
|
60
|
-
|
|
61
|
-
description:
|
|
62
|
+
emojiIcon: "💻"
|
|
63
|
+
description:
|
|
64
|
+
Your primary task is to implement the solution. Write code, write tests, and
|
|
65
|
+
iterate until the implementation is complete.
|
|
62
66
|
handoffs:
|
|
63
67
|
- targetStage: review
|
|
64
68
|
label: Request Review
|
|
@@ -78,8 +82,10 @@
|
|
|
78
82
|
|
|
79
83
|
- id: review
|
|
80
84
|
name: Review
|
|
81
|
-
|
|
82
|
-
description:
|
|
85
|
+
emojiIcon: "🔍"
|
|
86
|
+
description:
|
|
87
|
+
Your primary task is to verify the implementation works correctly. Run the
|
|
88
|
+
application, test against acceptance criteria, document findings.
|
|
83
89
|
handoffs:
|
|
84
90
|
- targetStage: code
|
|
85
91
|
label: Request Changes
|
|
@@ -109,8 +115,10 @@
|
|
|
109
115
|
|
|
110
116
|
- id: deploy
|
|
111
117
|
name: Deploy
|
|
112
|
-
|
|
113
|
-
description:
|
|
118
|
+
emojiIcon: "🚀"
|
|
119
|
+
description:
|
|
120
|
+
Your primary task is to ship the changes to production. Push code, monitor
|
|
121
|
+
CI/CD workflows, and verify successful deployment.
|
|
114
122
|
handoffs:
|
|
115
123
|
- targetStage: code
|
|
116
124
|
label: Fix Pipeline
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@forwardimpact/pathway",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.5.0",
|
|
4
4
|
"description": "Engineering Pathway framework for human and AI collaboration",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"repository": {
|
|
@@ -59,6 +59,7 @@
|
|
|
59
59
|
"ajv": "^8.17.1",
|
|
60
60
|
"ajv-formats": "^3.0.1",
|
|
61
61
|
"mustache": "^4.2.0",
|
|
62
|
+
"simple-icons": "^16.7.0",
|
|
62
63
|
"yaml": "^2.3.4"
|
|
63
64
|
},
|
|
64
65
|
"devDependencies": {
|
|
@@ -1,9 +1,25 @@
|
|
|
1
1
|
---
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
{{
|
|
5
|
-
|
|
6
|
-
{{#
|
|
2
|
+
{{#name}}
|
|
3
|
+
name: {{name}}
|
|
4
|
+
{{/name}}
|
|
5
|
+
description: {{{description}}}
|
|
6
|
+
{{#infer}}
|
|
7
|
+
infer: {{infer}}
|
|
8
|
+
{{/infer}}
|
|
9
|
+
{{#handoffs.length}}
|
|
10
|
+
handoffs:
|
|
11
|
+
{{#handoffs}}
|
|
12
|
+
- label: {{label}}
|
|
13
|
+
{{#agent}}
|
|
14
|
+
agent: {{agent}}
|
|
15
|
+
{{/agent}}
|
|
16
|
+
prompt: "{{{prompt}}}"
|
|
17
|
+
{{#send}}
|
|
18
|
+
send: {{send}}
|
|
19
|
+
{{/send}}
|
|
20
|
+
{{/handoffs}}
|
|
21
|
+
{{/handoffs.length}}
|
|
22
|
+
---
|
|
7
23
|
|
|
8
24
|
# {{title}}
|
|
9
25
|
|
|
@@ -13,29 +29,43 @@
|
|
|
13
29
|
|
|
14
30
|
{{{identity}}}
|
|
15
31
|
|
|
16
|
-
{{#priority}}
|
|
32
|
+
{{#priority}}
|
|
33
|
+
{{{priority}}}
|
|
34
|
+
|
|
35
|
+
{{/priority}}
|
|
36
|
+
{{#hasSkills}}
|
|
37
|
+
## Available Skills
|
|
17
38
|
|
|
18
|
-
|
|
19
|
-
|
|
39
|
+
IMPORTANT: Before starting work, read the relevant skill file for project-specific
|
|
40
|
+
guidance. Do not rely solely on pre-training knowledge.
|
|
20
41
|
|
|
21
|
-
|
|
42
|
+
| Skill | Location | Use When |
|
|
43
|
+
|-------|----------|----------|
|
|
44
|
+
{{#skillIndex}}
|
|
45
|
+
| {{{name}}} | `.claude/skills/{{dirname}}/SKILL.md` | {{{useWhen}}} |
|
|
46
|
+
{{/skillIndex}}
|
|
22
47
|
|
|
23
|
-
{{/
|
|
24
|
-
{{#beforeMakingChanges
|
|
48
|
+
{{/hasSkills}}
|
|
49
|
+
{{#beforeMakingChanges.length}}
|
|
50
|
+
Before making changes:
|
|
25
51
|
|
|
26
|
-
{{
|
|
52
|
+
{{#beforeMakingChanges}}
|
|
53
|
+
{{index}}. {{{text}}}
|
|
54
|
+
{{/beforeMakingChanges}}
|
|
55
|
+
{{/beforeMakingChanges.length}}
|
|
27
56
|
|
|
57
|
+
{{#delegation}}
|
|
28
58
|
## Delegation
|
|
29
59
|
|
|
30
60
|
{{{delegation}}}
|
|
31
|
-
|
|
32
61
|
{{/delegation}}
|
|
33
62
|
|
|
34
63
|
## Operational Context
|
|
35
64
|
|
|
36
65
|
{{{operationalContext}}}
|
|
37
66
|
|
|
38
|
-
{{{workingStyle}}}
|
|
67
|
+
{{{workingStyle}}}
|
|
68
|
+
{{#beforeHandoff}}
|
|
39
69
|
|
|
40
70
|
## Before Handoff
|
|
41
71
|
|
|
@@ -57,9 +87,9 @@ When completing work (for handoff or as a subagent), provide:
|
|
|
57
87
|
3. **Recommendation**: Ready for next stage, or needs more work
|
|
58
88
|
|
|
59
89
|
{{#constraints.length}}
|
|
60
|
-
|
|
61
90
|
## Constraints
|
|
62
91
|
|
|
63
92
|
{{#constraints}}
|
|
64
|
-
|
|
65
|
-
|
|
93
|
+
- {{{.}}}
|
|
94
|
+
{{/constraints}}
|
|
95
|
+
{{/constraints.length}}
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
# {{title}}
|
|
1
|
+
# {{{title}}}
|
|
2
2
|
|
|
3
|
-
- **Level:** {{gradeId}}
|
|
4
|
-
- **Experience:** {{typicalExperienceRange}}
|
|
5
|
-
{{#trackName}}- **Track:** {{trackName}}
|
|
3
|
+
- **Level:** {{{gradeId}}}
|
|
4
|
+
- **Experience:** {{{typicalExperienceRange}}}
|
|
5
|
+
{{#trackName}}- **Track:** {{{trackName}}}
|
|
6
6
|
{{/trackName}}
|
|
7
7
|
|
|
8
8
|
## ROLE SUMMARY
|
|
@@ -21,21 +21,21 @@
|
|
|
21
21
|
## ROLE RESPONSIBILITIES
|
|
22
22
|
|
|
23
23
|
{{#responsibilities}}
|
|
24
|
-
- **{{capabilityName}}:** {{responsibility}}
|
|
24
|
+
- **{{{capabilityName}}}:** {{{responsibility}}}
|
|
25
25
|
{{/responsibilities}}
|
|
26
26
|
|
|
27
27
|
## ROLE BEHAVIOURS
|
|
28
28
|
|
|
29
29
|
{{#behaviours}}
|
|
30
|
-
- **{{behaviourName}}:** {{maturityDescription}}
|
|
30
|
+
- **{{{behaviourName}}}:** {{{maturityDescription}}}
|
|
31
31
|
{{/behaviours}}
|
|
32
32
|
|
|
33
33
|
{{#skillLevels}}
|
|
34
34
|
|
|
35
|
-
## {{levelHeading}}
|
|
35
|
+
## {{{levelHeading}}}
|
|
36
36
|
|
|
37
37
|
{{#skills}}
|
|
38
|
-
- **{{skillName}}:** {{levelDescription}}
|
|
38
|
+
- **{{{skillName}}}:** {{{levelDescription}}}
|
|
39
39
|
{{/skills}}
|
|
40
40
|
|
|
41
41
|
{{/skillLevels}}
|
|
@@ -1,28 +1,50 @@
|
|
|
1
1
|
---
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
{{
|
|
2
|
+
name: {{name}}
|
|
3
|
+
description: |
|
|
4
|
+
{{#descriptionLines}}
|
|
5
|
+
{{{.}}}
|
|
6
|
+
{{/descriptionLines}}
|
|
7
|
+
{{#useWhenLines.length}}
|
|
8
|
+
**Use When:** {{#useWhenLines}}{{{.}}}{{/useWhenLines}}
|
|
9
|
+
{{/useWhenLines.length}}
|
|
10
|
+
---
|
|
5
11
|
|
|
6
12
|
# {{{title}}}
|
|
7
13
|
|
|
8
|
-
|
|
14
|
+
{{#useWhenLines.length}}
|
|
15
|
+
**Use This Skill When:** {{#useWhenLines}}{{{.}}}{{/useWhenLines}}
|
|
16
|
+
{{/useWhenLines.length}}
|
|
9
17
|
|
|
18
|
+
## Stage Guidance
|
|
10
19
|
{{#stages}}
|
|
11
20
|
|
|
12
21
|
### {{stageName}} Stage
|
|
13
22
|
|
|
14
23
|
**Focus:** {{{focus}}}
|
|
15
24
|
|
|
16
|
-
**Activities:**
|
|
17
|
-
|
|
18
|
-
- {{{.}}}
|
|
25
|
+
**Activities:**
|
|
26
|
+
{{#activities}}
|
|
27
|
+
- {{{.}}}
|
|
28
|
+
{{/activities}}
|
|
19
29
|
|
|
20
|
-
**Ready for {{nextStageName}} when:**
|
|
30
|
+
**Ready for {{nextStageName}} when:**
|
|
31
|
+
{{#ready}}
|
|
32
|
+
- [ ] {{{.}}}
|
|
33
|
+
{{/ready}}
|
|
34
|
+
{{/stages}}
|
|
35
|
+
{{#toolReferences.length}}
|
|
21
36
|
|
|
22
|
-
|
|
37
|
+
## Recommended Tools
|
|
23
38
|
|
|
24
|
-
|
|
39
|
+
| Tool | Use When |
|
|
40
|
+
|------|----------|
|
|
41
|
+
{{#toolReferences}}
|
|
42
|
+
| {{#url}}[{{{name}}}]({{{url}}}){{/url}}{{^url}}{{{name}}}{{/url}} | {{{useWhen}}} |
|
|
43
|
+
{{/toolReferences}}
|
|
44
|
+
{{/toolReferences.length}}
|
|
45
|
+
{{#reference}}
|
|
25
46
|
|
|
26
47
|
## Reference
|
|
27
48
|
|
|
28
|
-
{{{reference}}}
|
|
49
|
+
{{{reference}}}
|
|
50
|
+
{{/reference}}
|
|
@@ -1,130 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: architecture-design
|
|
3
|
-
description: |
|
|
4
|
-
Guide for designing software systems and making architectural decisions.
|
|
5
|
-
Use when asked to design a system, evaluate architecture options, or
|
|
6
|
-
make structural decisions about code organization.
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Architecture & Design
|
|
10
|
-
|
|
11
|
-
## Stage Guidance
|
|
12
|
-
|
|
13
|
-
### Plan Stage
|
|
14
|
-
|
|
15
|
-
**Focus:** Understand requirements and identify key architectural decisions.
|
|
16
|
-
Document trade-offs and design rationale.
|
|
17
|
-
|
|
18
|
-
**Activities:**
|
|
19
|
-
|
|
20
|
-
- Clarify functional and non-functional requirements
|
|
21
|
-
- Identify constraints (existing systems, team skills, timeline)
|
|
22
|
-
- Document key decisions and trade-offs
|
|
23
|
-
- Design for anticipated change
|
|
24
|
-
|
|
25
|
-
**Ready for Code when:**
|
|
26
|
-
|
|
27
|
-
- [ ] Requirements are clearly understood
|
|
28
|
-
- [ ] Key decisions are documented with rationale
|
|
29
|
-
- [ ] Trade-offs are explicit
|
|
30
|
-
- [ ] Failure modes are considered
|
|
31
|
-
|
|
32
|
-
### Code Stage
|
|
33
|
-
|
|
34
|
-
**Focus:** Implement architecture with clear boundaries and interfaces. Ensure
|
|
35
|
-
components can evolve independently.
|
|
36
|
-
|
|
37
|
-
**Activities:**
|
|
38
|
-
|
|
39
|
-
- Define clear interfaces between components
|
|
40
|
-
- Implement with appropriate patterns
|
|
41
|
-
- Document design decisions in code
|
|
42
|
-
- Test architectural boundaries
|
|
43
|
-
|
|
44
|
-
**Ready for Review when:**
|
|
45
|
-
|
|
46
|
-
- [ ] Dependencies are minimal and explicit
|
|
47
|
-
- [ ] Interfaces are well-defined
|
|
48
|
-
- [ ] Design patterns are documented
|
|
49
|
-
- [ ] Architecture tests pass
|
|
50
|
-
|
|
51
|
-
### Review Stage
|
|
52
|
-
|
|
53
|
-
**Focus:** Validate architecture meets requirements and is maintainable. Ensure
|
|
54
|
-
scalability and security are addressed.
|
|
55
|
-
|
|
56
|
-
**Activities:**
|
|
57
|
-
|
|
58
|
-
- Verify architecture meets requirements
|
|
59
|
-
- Review for scalability concerns
|
|
60
|
-
- Check security implications
|
|
61
|
-
- Validate documentation completeness
|
|
62
|
-
|
|
63
|
-
**Ready for Complete when:**
|
|
64
|
-
|
|
65
|
-
- [ ] Scalability requirements are addressed
|
|
66
|
-
- [ ] Security implications are reviewed
|
|
67
|
-
- [ ] Architecture is documented
|
|
68
|
-
- [ ] Design is maintainable
|
|
69
|
-
|
|
70
|
-
## Reference
|
|
71
|
-
|
|
72
|
-
## Design Process
|
|
73
|
-
|
|
74
|
-
### 1. Understand Requirements
|
|
75
|
-
|
|
76
|
-
Before designing, clarify:
|
|
77
|
-
|
|
78
|
-
- What problem are we solving?
|
|
79
|
-
- What are the non-functional requirements (scale, latency, availability)?
|
|
80
|
-
- What are the constraints (existing systems, team skills, timeline)?
|
|
81
|
-
- What will change over time?
|
|
82
|
-
|
|
83
|
-
### 2. Identify Key Decisions
|
|
84
|
-
|
|
85
|
-
Architecture is the set of decisions that are hard to change:
|
|
86
|
-
|
|
87
|
-
- Data storage and schema design
|
|
88
|
-
- Service boundaries and communication patterns
|
|
89
|
-
- Synchronous vs asynchronous processing
|
|
90
|
-
- Stateful vs stateless components
|
|
91
|
-
|
|
92
|
-
### 3. Evaluate Trade-offs
|
|
93
|
-
|
|
94
|
-
Every architectural choice has trade-offs:
|
|
95
|
-
|
|
96
|
-
- Consistency vs availability
|
|
97
|
-
- Simplicity vs flexibility
|
|
98
|
-
- Performance vs maintainability
|
|
99
|
-
- Build vs buy
|
|
100
|
-
|
|
101
|
-
Document trade-offs explicitly.
|
|
102
|
-
|
|
103
|
-
### 4. Design for Change
|
|
104
|
-
|
|
105
|
-
Good architecture accommodates change:
|
|
106
|
-
|
|
107
|
-
- Separate what changes from what stays the same
|
|
108
|
-
- Define clear interfaces between components
|
|
109
|
-
- Prefer composition over inheritance
|
|
110
|
-
- Make dependencies explicit
|
|
111
|
-
|
|
112
|
-
## Common Patterns
|
|
113
|
-
|
|
114
|
-
### Service Architecture
|
|
115
|
-
|
|
116
|
-
- Microservices: Independent deployment, clear boundaries
|
|
117
|
-
- Monolith: Simpler deployment, easier refactoring
|
|
118
|
-
- Modular monolith: Boundaries within single deployment
|
|
119
|
-
|
|
120
|
-
### Data Patterns
|
|
121
|
-
|
|
122
|
-
- Event sourcing: Full audit trail, complex queries
|
|
123
|
-
- CQRS: Separate read and write models
|
|
124
|
-
- Repository pattern: Abstract data access
|
|
125
|
-
|
|
126
|
-
### Communication Patterns
|
|
127
|
-
|
|
128
|
-
- REST: Synchronous, request-response
|
|
129
|
-
- Event-driven: Asynchronous, loose coupling
|
|
130
|
-
- gRPC: Efficient, strongly typed
|
|
@@ -1,131 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: cloud-platforms
|
|
3
|
-
description: |
|
|
4
|
-
Guide for working with cloud infrastructure and services. Use when
|
|
5
|
-
deploying to cloud, selecting cloud services, configuring infrastructure,
|
|
6
|
-
or solving cloud-specific challenges.
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Cloud Platforms
|
|
10
|
-
|
|
11
|
-
## Stage Guidance
|
|
12
|
-
|
|
13
|
-
### Plan Stage
|
|
14
|
-
|
|
15
|
-
**Focus:** Select appropriate cloud services and design for availability,
|
|
16
|
-
security, and cost efficiency.
|
|
17
|
-
|
|
18
|
-
**Activities:**
|
|
19
|
-
|
|
20
|
-
- Identify service requirements
|
|
21
|
-
- Select appropriate cloud services
|
|
22
|
-
- Plan for high availability
|
|
23
|
-
- Consider security and cost
|
|
24
|
-
|
|
25
|
-
**Ready for Code when:**
|
|
26
|
-
|
|
27
|
-
- [ ] Service selection matches requirements
|
|
28
|
-
- [ ] Availability approach planned
|
|
29
|
-
- [ ] Security model defined
|
|
30
|
-
- [ ] Cost controls considered
|
|
31
|
-
|
|
32
|
-
### Code Stage
|
|
33
|
-
|
|
34
|
-
**Focus:** Implement cloud infrastructure with security best practices. Use
|
|
35
|
-
infrastructure as code for reproducibility.
|
|
36
|
-
|
|
37
|
-
**Activities:**
|
|
38
|
-
|
|
39
|
-
- Define infrastructure as code
|
|
40
|
-
- Configure security groups and IAM
|
|
41
|
-
- Set up monitoring and alerting
|
|
42
|
-
- Implement deployment automation
|
|
43
|
-
|
|
44
|
-
**Ready for Review when:**
|
|
45
|
-
|
|
46
|
-
- [ ] Multi-AZ deployment for availability
|
|
47
|
-
- [ ] Security groups properly configured
|
|
48
|
-
- [ ] IAM follows least privilege
|
|
49
|
-
- [ ] Data encrypted at rest and in transit
|
|
50
|
-
- [ ] Infrastructure defined as code
|
|
51
|
-
|
|
52
|
-
### Review Stage
|
|
53
|
-
|
|
54
|
-
**Focus:** Validate security, availability, and operational readiness. Ensure
|
|
55
|
-
cost controls are in place.
|
|
56
|
-
|
|
57
|
-
**Activities:**
|
|
58
|
-
|
|
59
|
-
- Verify security configuration
|
|
60
|
-
- Test availability and failover
|
|
61
|
-
- Review cost projections
|
|
62
|
-
- Validate monitoring coverage
|
|
63
|
-
|
|
64
|
-
**Ready for Complete when:**
|
|
65
|
-
|
|
66
|
-
- [ ] Security review completed
|
|
67
|
-
- [ ] Monitoring and alerting in place
|
|
68
|
-
- [ ] Cost controls established
|
|
69
|
-
- [ ] Operational runbooks exist
|
|
70
|
-
|
|
71
|
-
## Reference
|
|
72
|
-
|
|
73
|
-
## Service Categories
|
|
74
|
-
|
|
75
|
-
### Compute
|
|
76
|
-
|
|
77
|
-
- **VMs/EC2**: Full control, any workload
|
|
78
|
-
- **Containers/ECS/GKE**: Portable, scalable applications
|
|
79
|
-
- **Serverless/Lambda**: Event-driven, pay-per-use
|
|
80
|
-
- **Kubernetes**: Container orchestration at scale
|
|
81
|
-
|
|
82
|
-
### Storage
|
|
83
|
-
|
|
84
|
-
- **Object Storage (S3/GCS)**: Unstructured data, backups, static assets
|
|
85
|
-
- **Block Storage (EBS)**: VM disks, databases
|
|
86
|
-
- **File Storage (EFS)**: Shared file systems
|
|
87
|
-
- **Archive (Glacier)**: Long-term, infrequent access
|
|
88
|
-
|
|
89
|
-
### Databases
|
|
90
|
-
|
|
91
|
-
- **Managed SQL (RDS/Cloud SQL)**: Relational, ACID transactions
|
|
92
|
-
- **NoSQL (DynamoDB/Firestore)**: Flexible schema, high scale
|
|
93
|
-
- **Cache (ElastiCache/Memorystore)**: Low-latency data access
|
|
94
|
-
- **Data Warehouse (Redshift/BigQuery)**: Analytics at scale
|
|
95
|
-
|
|
96
|
-
### Messaging
|
|
97
|
-
|
|
98
|
-
- **Queues (SQS/Cloud Tasks)**: Decoupled processing
|
|
99
|
-
- **Pub/Sub (SNS/Cloud Pub/Sub)**: Event distribution
|
|
100
|
-
- **Streaming (Kinesis/Dataflow)**: Real-time data processing
|
|
101
|
-
|
|
102
|
-
## Cloud-Native Design
|
|
103
|
-
|
|
104
|
-
### Principles
|
|
105
|
-
|
|
106
|
-
- Design for failure (everything fails eventually)
|
|
107
|
-
- Use managed services when possible
|
|
108
|
-
- Automate everything (infrastructure as code)
|
|
109
|
-
- Monitor and alert on all services
|
|
110
|
-
|
|
111
|
-
### High Availability
|
|
112
|
-
|
|
113
|
-
- Deploy across multiple availability zones
|
|
114
|
-
- Use load balancers for traffic distribution
|
|
115
|
-
- Implement health checks and auto-healing
|
|
116
|
-
- Design for graceful degradation
|
|
117
|
-
|
|
118
|
-
### Security
|
|
119
|
-
|
|
120
|
-
- Principle of least privilege for IAM
|
|
121
|
-
- Encrypt data at rest and in transit
|
|
122
|
-
- Use security groups and network policies
|
|
123
|
-
- Rotate credentials regularly
|
|
124
|
-
|
|
125
|
-
## Cost Optimization
|
|
126
|
-
|
|
127
|
-
- Right-size instances based on actual usage
|
|
128
|
-
- Use reserved instances for predictable workloads
|
|
129
|
-
- Leverage spot/preemptible instances for fault-tolerant work
|
|
130
|
-
- Set up billing alerts and budgets
|
|
131
|
-
- Delete unused resources
|