agentic-code 0.5.1
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/.agents/context-maps/task-rule-matrix.yaml +248 -0
- package/.agents/rules/contextual/architecture/implementation-approach.md +202 -0
- package/.agents/rules/core/ai-development-guide.md +272 -0
- package/.agents/rules/core/documentation-criteria.md +184 -0
- package/.agents/rules/core/integration-e2e-testing.md +76 -0
- package/.agents/rules/core/metacognition.md +153 -0
- package/.agents/rules/core/testing-strategy.md +230 -0
- package/.agents/rules/language/general/rules.md +117 -0
- package/.agents/rules/language/general/testing.md +257 -0
- package/.agents/rules/language/typescript/rules.md +178 -0
- package/.agents/rules/language/typescript/testing.md +284 -0
- package/.agents/tasks/acceptance-test-generation.md +461 -0
- package/.agents/tasks/code-review.md +207 -0
- package/.agents/tasks/implementation.md +199 -0
- package/.agents/tasks/integration-test-review.md +132 -0
- package/.agents/tasks/prd-creation.md +336 -0
- package/.agents/tasks/quality-assurance.md +219 -0
- package/.agents/tasks/task-analysis.md +263 -0
- package/.agents/tasks/technical-design.md +432 -0
- package/.agents/tasks/technical-document-review.md +254 -0
- package/.agents/tasks/work-planning.md +239 -0
- package/.agents/workflows/agentic-coding.md +333 -0
- package/AGENTS.md +156 -0
- package/LICENSE +21 -0
- package/README.md +268 -0
- package/bin/cli.js +117 -0
- package/package.json +45 -0
- package/scripts/setup.js +82 -0
|
@@ -0,0 +1,248 @@
|
|
|
1
|
+
# Task-Rule Mapping Matrix
|
|
2
|
+
# Maps tasks to relevant rules based on metadata and tags
|
|
3
|
+
# Used by task-analysis.md to recommend appropriate rules for each task type
|
|
4
|
+
|
|
5
|
+
rules:
|
|
6
|
+
# Core Rules
|
|
7
|
+
core/metacognition:
|
|
8
|
+
path: ".agents/rules/core/metacognition.md"
|
|
9
|
+
tags: [self-assessment, reflection, decision-checkpoint, quality-control]
|
|
10
|
+
when_to_load:
|
|
11
|
+
- "Task type changes (e.g., from design to implementation)"
|
|
12
|
+
- "Unexpected errors occur repeatedly"
|
|
13
|
+
- "Completing a meaningful unit of work"
|
|
14
|
+
- "Before starting new implementation"
|
|
15
|
+
typical_tasks: [all]
|
|
16
|
+
size: small
|
|
17
|
+
priority: always
|
|
18
|
+
description: "Self-assessment and reflection protocols for maintaining quality"
|
|
19
|
+
|
|
20
|
+
core/ai-development-guide:
|
|
21
|
+
path: ".agents/rules/core/ai-development-guide.md"
|
|
22
|
+
tags: [anti-patterns, debugging, best-practices, rule-of-three, technical-debt, impact-analysis, unused-code, code-deletion, implementation-completeness]
|
|
23
|
+
when_to_load:
|
|
24
|
+
- "Starting new implementation"
|
|
25
|
+
- "Code review and refactoring"
|
|
26
|
+
- "Debugging complex issues"
|
|
27
|
+
- "Technical decision making"
|
|
28
|
+
- "Impact analysis before changes"
|
|
29
|
+
typical_tasks: [implementation, debugging, refactoring]
|
|
30
|
+
size: medium
|
|
31
|
+
priority: high
|
|
32
|
+
description: "Anti-patterns, debugging techniques, development best practices, and implementation completeness assurance"
|
|
33
|
+
|
|
34
|
+
core/documentation-criteria:
|
|
35
|
+
path: ".agents/rules/core/documentation-criteria.md"
|
|
36
|
+
tags: [documentation, adr, design-doc, decision-matrix, scale-assessment]
|
|
37
|
+
when_to_load:
|
|
38
|
+
- "Task scale assessment (Small/Medium/Large)"
|
|
39
|
+
- "Architecture decisions needed"
|
|
40
|
+
- "Creating technical documentation"
|
|
41
|
+
- "New feature planning"
|
|
42
|
+
typical_tasks: [design, documentation, planning]
|
|
43
|
+
size: medium
|
|
44
|
+
priority: medium
|
|
45
|
+
description: "Criteria for when and how to create documentation"
|
|
46
|
+
|
|
47
|
+
core/testing-strategy:
|
|
48
|
+
path: ".agents/rules/core/testing-strategy.md"
|
|
49
|
+
tags: [testing, roi-calculation, test-selection, budget-enforcement, behavior-first]
|
|
50
|
+
when_to_load:
|
|
51
|
+
- "Generating acceptance tests from design documents"
|
|
52
|
+
- "Test prioritization and selection"
|
|
53
|
+
- "ROI-based test strategy decisions"
|
|
54
|
+
- "Preventing test over-generation"
|
|
55
|
+
typical_tasks: [test_generation]
|
|
56
|
+
size: large
|
|
57
|
+
priority: high
|
|
58
|
+
description: "ROI-based test selection framework with behavior-first filtering and budget enforcement"
|
|
59
|
+
|
|
60
|
+
core/integration-e2e-testing:
|
|
61
|
+
path: ".agents/rules/core/integration-e2e-testing.md"
|
|
62
|
+
tags: [testing, integration-test, e2e-test, behavior-first, mock-boundary, test-review]
|
|
63
|
+
when_to_load:
|
|
64
|
+
- "Generating integration/E2E test skeletons"
|
|
65
|
+
- "Implementing integration/E2E tests"
|
|
66
|
+
- "Reviewing test implementation quality"
|
|
67
|
+
typical_tasks: [test_generation, test_review]
|
|
68
|
+
size: small
|
|
69
|
+
priority: high
|
|
70
|
+
description: "Integration and E2E test design, implementation rules, and review criteria"
|
|
71
|
+
|
|
72
|
+
# Language Rules (currently TypeScript, but concepts are universal)
|
|
73
|
+
language/rules:
|
|
74
|
+
path: ".agents/rules/language/rules.md"
|
|
75
|
+
tags: [implementation, coding-style, type-safety, error-handling, refactoring, clean-code, solid-principles]
|
|
76
|
+
when_to_load:
|
|
77
|
+
- "Writing or modifying code"
|
|
78
|
+
- "Code review"
|
|
79
|
+
- "Refactoring existing code"
|
|
80
|
+
- "Implementing new features"
|
|
81
|
+
typical_tasks: [implementation, refactoring]
|
|
82
|
+
size: large
|
|
83
|
+
priority: high
|
|
84
|
+
description: "Language-specific coding standards and best practices"
|
|
85
|
+
universal_concepts:
|
|
86
|
+
- "YAGNI principle"
|
|
87
|
+
- "DRY principle"
|
|
88
|
+
- "Error handling patterns"
|
|
89
|
+
- "Dependency injection"
|
|
90
|
+
- "Clean code principles"
|
|
91
|
+
- "Type/static safety (for typed languages)"
|
|
92
|
+
- "Async/concurrent programming patterns"
|
|
93
|
+
- "Function composition over classes"
|
|
94
|
+
|
|
95
|
+
language/testing:
|
|
96
|
+
path: ".agents/rules/language/testing.md"
|
|
97
|
+
tags: [testing, tdd, quality-assurance, coverage, unit-tests, integration-tests, verify-phase, test-skeleton]
|
|
98
|
+
when_to_load:
|
|
99
|
+
- "Writing tests"
|
|
100
|
+
- "Bug fixing (test-first)"
|
|
101
|
+
- "Quality checks"
|
|
102
|
+
- "Refactoring (ensuring safety)"
|
|
103
|
+
- "VERIFY phase execution (mandatory)"
|
|
104
|
+
- "Test skeleton generation from acceptance criteria"
|
|
105
|
+
typical_tasks: [implementation, debugging, quality-check, test_generation]
|
|
106
|
+
size: medium
|
|
107
|
+
priority: always
|
|
108
|
+
description: "Testing standards, TDD practices, and mandatory quality checks"
|
|
109
|
+
universal_concepts:
|
|
110
|
+
- "Red-Green-Refactor cycle"
|
|
111
|
+
- "Test independence"
|
|
112
|
+
- "AAA pattern (Arrange-Act-Assert)"
|
|
113
|
+
- "Coverage requirements (70%+)"
|
|
114
|
+
- "Mock/stub patterns"
|
|
115
|
+
- "Unit vs Integration testing"
|
|
116
|
+
- "Test-first development"
|
|
117
|
+
|
|
118
|
+
contextual/architecture/implementation-approach:
|
|
119
|
+
path: ".agents/rules/contextual/architecture/implementation-approach.md"
|
|
120
|
+
tags: [strategy-selection, task-decomposition, verification-levels, integration-points]
|
|
121
|
+
when_to_load:
|
|
122
|
+
- "Medium/Large scale tasks (3+ files)"
|
|
123
|
+
- "Implementation strategy selection"
|
|
124
|
+
- "Task breakdown and planning"
|
|
125
|
+
- "Choosing between vertical/horizontal slicing"
|
|
126
|
+
typical_tasks: [planning, design, implementation]
|
|
127
|
+
size: medium
|
|
128
|
+
priority: conditional
|
|
129
|
+
description: "Strategy selection for implementation approaches (vertical/horizontal slicing)"
|
|
130
|
+
|
|
131
|
+
|
|
132
|
+
# Task Type to Rule Mapping
|
|
133
|
+
task_mappings:
|
|
134
|
+
prd_creation:
|
|
135
|
+
required:
|
|
136
|
+
- "core/documentation-criteria"
|
|
137
|
+
recommended:
|
|
138
|
+
- "core/metacognition"
|
|
139
|
+
|
|
140
|
+
implementation:
|
|
141
|
+
required:
|
|
142
|
+
- "language/rules"
|
|
143
|
+
- "language/testing" # TDD is mandatory
|
|
144
|
+
- "core/ai-development-guide"
|
|
145
|
+
recommended:
|
|
146
|
+
- "core/metacognition"
|
|
147
|
+
conditional:
|
|
148
|
+
- "contextual/architecture/implementation-approach" # For Medium/Large scale
|
|
149
|
+
|
|
150
|
+
debugging:
|
|
151
|
+
required:
|
|
152
|
+
- "core/ai-development-guide"
|
|
153
|
+
- "language/testing"
|
|
154
|
+
recommended:
|
|
155
|
+
- "language/rules"
|
|
156
|
+
- "core/metacognition"
|
|
157
|
+
|
|
158
|
+
design:
|
|
159
|
+
required:
|
|
160
|
+
- "core/documentation-criteria"
|
|
161
|
+
conditional:
|
|
162
|
+
- "contextual/architecture/implementation-approach" # Required for Medium/Large scale (3+ files)
|
|
163
|
+
|
|
164
|
+
documentation:
|
|
165
|
+
required:
|
|
166
|
+
- "core/documentation-criteria"
|
|
167
|
+
|
|
168
|
+
refactoring:
|
|
169
|
+
required:
|
|
170
|
+
- "language/rules"
|
|
171
|
+
- "language/testing"
|
|
172
|
+
- "core/ai-development-guide"
|
|
173
|
+
recommended:
|
|
174
|
+
- "core/metacognition"
|
|
175
|
+
|
|
176
|
+
research:
|
|
177
|
+
recommended:
|
|
178
|
+
- "core/metacognition"
|
|
179
|
+
|
|
180
|
+
test_generation:
|
|
181
|
+
required:
|
|
182
|
+
- "language/testing" # Test framework patterns and conventions
|
|
183
|
+
- "core/documentation-criteria" # Design document analysis
|
|
184
|
+
- "core/testing-strategy" # ROI-based test selection
|
|
185
|
+
- "core/integration-e2e-testing" # Integration/E2E test design rules
|
|
186
|
+
recommended:
|
|
187
|
+
- "core/metacognition"
|
|
188
|
+
|
|
189
|
+
integration_test_review:
|
|
190
|
+
required:
|
|
191
|
+
- "language/testing"
|
|
192
|
+
- "core/integration-e2e-testing"
|
|
193
|
+
recommended:
|
|
194
|
+
- "core/metacognition"
|
|
195
|
+
description: "Review integration and E2E test implementations"
|
|
196
|
+
|
|
197
|
+
code_review:
|
|
198
|
+
required:
|
|
199
|
+
- "language/rules"
|
|
200
|
+
- "core/ai-development-guide"
|
|
201
|
+
recommended:
|
|
202
|
+
- "core/metacognition"
|
|
203
|
+
description: "Review implementation against Design Doc compliance"
|
|
204
|
+
|
|
205
|
+
technical_document_review:
|
|
206
|
+
required:
|
|
207
|
+
- "core/documentation-criteria"
|
|
208
|
+
conditional:
|
|
209
|
+
- "core/testing-strategy"
|
|
210
|
+
- "language/rules"
|
|
211
|
+
recommended:
|
|
212
|
+
- "core/metacognition"
|
|
213
|
+
description: "Review technical documents (Design Docs, ADRs)"
|
|
214
|
+
|
|
215
|
+
# Scale-based Rule Loading
|
|
216
|
+
scale_mappings:
|
|
217
|
+
small: # 1-2 files
|
|
218
|
+
load_immediately:
|
|
219
|
+
- "language/rules"
|
|
220
|
+
load_on_demand: []
|
|
221
|
+
|
|
222
|
+
medium: # 3-5 files
|
|
223
|
+
load_immediately:
|
|
224
|
+
- "language/rules"
|
|
225
|
+
- "language/testing" # TDD is mandatory
|
|
226
|
+
- "core/documentation-criteria"
|
|
227
|
+
- "contextual/architecture/implementation-approach" # Required for approach selection
|
|
228
|
+
load_on_demand:
|
|
229
|
+
- "core/ai-development-guide"
|
|
230
|
+
|
|
231
|
+
large: # 6+ files
|
|
232
|
+
load_immediately:
|
|
233
|
+
- "core/documentation-criteria"
|
|
234
|
+
- "contextual/architecture/implementation-approach"
|
|
235
|
+
load_on_demand:
|
|
236
|
+
- "language/rules"
|
|
237
|
+
- "language/testing"
|
|
238
|
+
- "core/ai-development-guide"
|
|
239
|
+
|
|
240
|
+
# Metadata for rule selection algorithm
|
|
241
|
+
selection_rules:
|
|
242
|
+
- "Always load core/metacognition at session start"
|
|
243
|
+
- "Load language/rules when any code modification is involved"
|
|
244
|
+
- "Load language/testing for ALL implementation tasks (TDD mandatory)"
|
|
245
|
+
- "Load implementation-approach for Medium/Large scale (3+ files)"
|
|
246
|
+
- "Execute ALL quality check commands in VERIFY phase with 0 errors"
|
|
247
|
+
- "Progressive loading: start with minimum, add as needed"
|
|
248
|
+
- "Unload task-specific rules after task completion"
|
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
# Implementation Strategy Selection Framework (Meta-cognitive Approach)
|
|
2
|
+
|
|
3
|
+
An implementation strategy selection framework based on meta-cognitive thinking. Derives optimal implementation approaches through a systematic decision process from understanding existing implementations to constraint compatibility.
|
|
4
|
+
|
|
5
|
+
## Meta-cognitive Strategy Selection Process
|
|
6
|
+
|
|
7
|
+
### Step 1: Comprehensive Current State Analysis
|
|
8
|
+
|
|
9
|
+
**Core Question**: "What does the existing implementation look like?"
|
|
10
|
+
|
|
11
|
+
#### Analysis Framework
|
|
12
|
+
```yaml
|
|
13
|
+
Architecture Analysis:
|
|
14
|
+
- Current responsibility separation and improvement potential
|
|
15
|
+
- Data flow identification and evaluation
|
|
16
|
+
- Dependency visualization and impact scope
|
|
17
|
+
- Technical debt quantification
|
|
18
|
+
|
|
19
|
+
Implementation Quality Assessment:
|
|
20
|
+
- Code quality and maintainability
|
|
21
|
+
- Test coverage and reliability
|
|
22
|
+
- Performance characteristics
|
|
23
|
+
- Security considerations
|
|
24
|
+
|
|
25
|
+
Historical Context Understanding:
|
|
26
|
+
- Why did it become the current form?
|
|
27
|
+
- Validity check of past decisions
|
|
28
|
+
- Changes in technical constraints
|
|
29
|
+
- Evolution of business requirements
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
#### Meta-cognitive Question List
|
|
33
|
+
- What is the true responsibility of this implementation?
|
|
34
|
+
- Which parts are business essence and which derive from technical constraints?
|
|
35
|
+
- What dependencies or implicit preconditions are unclear from the code?
|
|
36
|
+
- What benefits and constraints does the current design bring?
|
|
37
|
+
|
|
38
|
+
### Step 2: Strategy Exploration and Creation
|
|
39
|
+
|
|
40
|
+
**Core Question**: "When determining before → after, what implementation patterns or strategies should be referenced?"
|
|
41
|
+
|
|
42
|
+
#### Strategy Discovery Process
|
|
43
|
+
```yaml
|
|
44
|
+
Research and Exploration:
|
|
45
|
+
- Implementation examples and patterns from similar tech stacks (research online)
|
|
46
|
+
- Approach collection from projects handling similar challenges
|
|
47
|
+
- Open source implementation references
|
|
48
|
+
- Technical literature and blog research
|
|
49
|
+
|
|
50
|
+
Creative Thinking:
|
|
51
|
+
- Sequential/parallel application of multiple strategies
|
|
52
|
+
- Design based on project time/human/technical constraints
|
|
53
|
+
- Phase division and milestone setting
|
|
54
|
+
- Pre-design of necessary extension points
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
#### Reference Strategy Patterns (Creative Combinations Encouraged)
|
|
58
|
+
|
|
59
|
+
**Legacy Handling Strategies**:
|
|
60
|
+
- Strangler Pattern: Gradual migration through phased replacement
|
|
61
|
+
- Facade Pattern: Complexity hiding through unified interface
|
|
62
|
+
- Adapter Pattern: Bridge with existing systems
|
|
63
|
+
|
|
64
|
+
**New Development Strategies**:
|
|
65
|
+
- Feature-driven Development: Vertical implementation prioritizing user value
|
|
66
|
+
- Foundation-driven Development: Foundation-first construction prioritizing stability
|
|
67
|
+
- Risk-driven Development: Prioritize addressing maximum risk elements
|
|
68
|
+
|
|
69
|
+
**Integration/Migration Strategies**:
|
|
70
|
+
- Proxy Pattern: Transparent feature extension
|
|
71
|
+
- Decorator Pattern: Phased enhancement of existing features
|
|
72
|
+
- Bridge Pattern: Flexibility through abstraction
|
|
73
|
+
|
|
74
|
+
**Important**: The optimal solution is discovered through creative thinking according to each project's context.
|
|
75
|
+
|
|
76
|
+
### Step 3: Risk Assessment and Control
|
|
77
|
+
|
|
78
|
+
**Core Question**: "What risks arise when applying this to existing implementation, and what's the best way to control them?"
|
|
79
|
+
|
|
80
|
+
#### Risk Analysis Matrix
|
|
81
|
+
```yaml
|
|
82
|
+
Technical Risks:
|
|
83
|
+
- Impact on existing systems
|
|
84
|
+
- Data consistency assurance
|
|
85
|
+
- Performance degradation possibility
|
|
86
|
+
- Integration complexity
|
|
87
|
+
|
|
88
|
+
Operational Risks:
|
|
89
|
+
- Service availability impact
|
|
90
|
+
- Deployment downtime
|
|
91
|
+
- Monitoring/operation process changes
|
|
92
|
+
- Failure rollback procedures
|
|
93
|
+
|
|
94
|
+
Project Risks:
|
|
95
|
+
- Schedule delay possibility
|
|
96
|
+
- Technology learning costs
|
|
97
|
+
- Quality requirement achievement
|
|
98
|
+
- Cross-team coordination complexity
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
#### Risk Control Strategies
|
|
102
|
+
```yaml
|
|
103
|
+
Preventive Measures:
|
|
104
|
+
- Phased migration to new system without service disruption
|
|
105
|
+
- Verification through parallel operation of old and new systems
|
|
106
|
+
- Addition of integration and regression tests for new features
|
|
107
|
+
- Pre-implementation setup of performance and error monitoring
|
|
108
|
+
|
|
109
|
+
Incident Response:
|
|
110
|
+
- Clarify rollback procedures and conditions to old system
|
|
111
|
+
- Prepare log analysis and metrics dashboards
|
|
112
|
+
- Define communication system and role assignments for failures
|
|
113
|
+
- Document partial service continuation procedures
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
### Step 4: Constraint Compatibility Verification
|
|
117
|
+
|
|
118
|
+
**Core Question**: "What are this project's constraints?"
|
|
119
|
+
|
|
120
|
+
#### Constraint Checklist
|
|
121
|
+
```yaml
|
|
122
|
+
Technical Constraints:
|
|
123
|
+
- Compatibility with existing libraries/frameworks
|
|
124
|
+
- Server resource, network, database capacity limits
|
|
125
|
+
- Mandatory requirements like data protection, access control, audit logging
|
|
126
|
+
- Numerical targets like response time <5 seconds, 99.9% uptime
|
|
127
|
+
|
|
128
|
+
Temporal Constraints:
|
|
129
|
+
- Project deadlines and priorities
|
|
130
|
+
- Dependencies with other projects
|
|
131
|
+
- Milestone/release plans
|
|
132
|
+
- Learning/acquisition period considerations
|
|
133
|
+
|
|
134
|
+
Resource Constraints:
|
|
135
|
+
- Team size, new technology learning time, existing skill sets
|
|
136
|
+
- Developer work hours, server resources, operational system allocation
|
|
137
|
+
- Project budget ceiling, running cost ceiling
|
|
138
|
+
- External vendor support deadlines, SLAs, contract terms
|
|
139
|
+
|
|
140
|
+
Business Constraints:
|
|
141
|
+
- Market launch timing requirements
|
|
142
|
+
- Customer impact minimization requirements
|
|
143
|
+
- Regulatory/industry standard compliance
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
### Step 5: Implementation Approach Decision
|
|
147
|
+
|
|
148
|
+
Select optimal solution from basic implementation approaches (creative combinations encouraged):
|
|
149
|
+
|
|
150
|
+
#### Vertical Slice (Feature-driven)
|
|
151
|
+
**Characteristics**: Vertical implementation across all layers by feature unit
|
|
152
|
+
**Application Conditions**: Low inter-feature dependencies, output in user-usable form, changes needed across all architecture layers
|
|
153
|
+
**Verification Method**: End-user value delivery at each feature completion
|
|
154
|
+
|
|
155
|
+
#### Horizontal Slice (Foundation-driven)
|
|
156
|
+
**Characteristics**: Phased construction by architecture layer
|
|
157
|
+
**Application Conditions**: Foundation system stability important, multiple features depend on common foundation, layer-by-layer verification effective
|
|
158
|
+
**Verification Method**: Integrated operation verification when all foundation layers complete
|
|
159
|
+
|
|
160
|
+
#### Hybrid (Creative Combination)
|
|
161
|
+
**Characteristics**: Flexible combination according to project characteristics
|
|
162
|
+
**Application Conditions**: Unclear requirements, need to change approach per phase, transition from prototyping to full implementation
|
|
163
|
+
**Verification Method**: Verify at appropriate L1/L2/L3 levels according to each phase's goals
|
|
164
|
+
|
|
165
|
+
### Step 6: Decision Rationale Documentation
|
|
166
|
+
|
|
167
|
+
**Design Doc Documentation**: Clearly specify implementation strategy selection reasons and rationale.
|
|
168
|
+
|
|
169
|
+
## Verification Level Definitions
|
|
170
|
+
|
|
171
|
+
Priority for completion verification of each task:
|
|
172
|
+
|
|
173
|
+
- **L1: Functional Operation Verification** - Operates as end-user feature (e.g., search executable)
|
|
174
|
+
- **L2: Test Operation Verification** - New tests added and passing (e.g., type definition tests)
|
|
175
|
+
- **L3: Build Success Verification** - No compile errors (e.g., interface definitions)
|
|
176
|
+
|
|
177
|
+
**Priority**: L1 > L2 > L3 in order of verifiability importance
|
|
178
|
+
|
|
179
|
+
## Integration Point Definitions
|
|
180
|
+
|
|
181
|
+
Define integration points according to selected strategy:
|
|
182
|
+
- **Strangler-based**: When switching between old and new systems for each feature
|
|
183
|
+
- **Feature-driven**: When users can actually use the feature
|
|
184
|
+
- **Foundation-driven**: When all architecture layers are ready and E2E tests pass
|
|
185
|
+
- **Hybrid**: When individual goals defined for each phase are achieved
|
|
186
|
+
|
|
187
|
+
## Anti-patterns
|
|
188
|
+
|
|
189
|
+
- **Pattern Fixation**: Selecting only from listed strategies without considering unique combinations
|
|
190
|
+
- **Insufficient Analysis**: Skipping Step 1 analysis framework before strategy selection
|
|
191
|
+
- **Risk Neglect**: Starting implementation without Step 3 risk analysis matrix
|
|
192
|
+
- **Constraint Ignorance**: Deciding strategy without checking Step 4 constraint checklist
|
|
193
|
+
- **Rationale Omission**: Selecting strategy without using Step 6 documentation template
|
|
194
|
+
|
|
195
|
+
## Guidelines for Meta-cognitive Execution
|
|
196
|
+
|
|
197
|
+
1. **Leverage Known Patterns**: Use as starting point, explore creative combinations
|
|
198
|
+
2. **Active Web Research**: Research implementation examples from similar tech stacks
|
|
199
|
+
3. **Apply 5 Whys**: Pursue root causes to grasp essence
|
|
200
|
+
4. **Multi-perspective Evaluation**: Comprehensively evaluate from each Step 1-4 perspective
|
|
201
|
+
5. **Creative Thinking**: Consider sequential application of multiple strategies and designs leveraging project-specific constraints
|
|
202
|
+
6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents
|