bc-code-intelligence-mcp 1.4.4 → 1.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/dist/config/config-loader.d.ts.map +1 -1
- package/dist/config/config-loader.js +33 -1
- package/dist/config/config-loader.js.map +1 -1
- package/dist/config/config-validator.d.ts.map +1 -1
- package/dist/config/config-validator.js +5 -1
- package/dist/config/config-validator.js.map +1 -1
- package/dist/index.d.ts +14 -0
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +272 -24
- package/dist/index.js.map +1 -1
- package/dist/layers/base-layer.d.ts +41 -17
- package/dist/layers/base-layer.d.ts.map +1 -1
- package/dist/layers/base-layer.js +103 -41
- package/dist/layers/base-layer.js.map +1 -1
- package/dist/layers/embedded-layer.d.ts +5 -2
- package/dist/layers/embedded-layer.d.ts.map +1 -1
- package/dist/layers/embedded-layer.js +58 -23
- package/dist/layers/embedded-layer.js.map +1 -1
- package/dist/layers/git-layer.d.ts +16 -1
- package/dist/layers/git-layer.d.ts.map +1 -1
- package/dist/layers/git-layer.js +118 -10
- package/dist/layers/git-layer.js.map +1 -1
- package/dist/layers/project-layer.d.ts +8 -0
- package/dist/layers/project-layer.d.ts.map +1 -1
- package/dist/layers/project-layer.js +33 -3
- package/dist/layers/project-layer.js.map +1 -1
- package/dist/services/methodology-service.d.ts.map +1 -1
- package/dist/services/methodology-service.js +5 -1
- package/dist/services/methodology-service.js.map +1 -1
- package/dist/services/multi-content-layer-service.d.ts +13 -0
- package/dist/services/multi-content-layer-service.d.ts.map +1 -1
- package/dist/services/multi-content-layer-service.js +59 -3
- package/dist/services/multi-content-layer-service.js.map +1 -1
- package/dist/services/roleplay-engine.d.ts.map +1 -1
- package/dist/services/roleplay-engine.js +4 -4
- package/dist/services/roleplay-engine.js.map +1 -1
- package/dist/tools/config-diagnostic-tools.d.ts +234 -0
- package/dist/tools/config-diagnostic-tools.d.ts.map +1 -0
- package/dist/tools/config-diagnostic-tools.js +887 -0
- package/dist/tools/config-diagnostic-tools.js.map +1 -0
- package/dist/tools/specialist-tools.d.ts.map +1 -1
- package/dist/tools/specialist-tools.js +7 -1
- package/dist/tools/specialist-tools.js.map +1 -1
- package/dist/tools/workspace-tools.d.ts +71 -0
- package/dist/tools/workspace-tools.d.ts.map +1 -0
- package/dist/tools/workspace-tools.js +134 -0
- package/dist/tools/workspace-tools.js.map +1 -0
- package/dist/types/bc-knowledge.d.ts +6 -0
- package/dist/types/bc-knowledge.d.ts.map +1 -1
- package/dist/types/bc-knowledge.js +3 -0
- package/dist/types/bc-knowledge.js.map +1 -1
- package/dist/types/config-types.d.ts +3 -0
- package/dist/types/config-types.d.ts.map +1 -1
- package/dist/types/config-types.js +5 -1
- package/dist/types/config-types.js.map +1 -1
- package/embedded-knowledge/domains/alex-architect/delegating-to-github-copilot-agents.md +371 -0
- package/embedded-knowledge/domains/alex-architect/object-id-ninja-integration.md +281 -0
- package/embedded-knowledge/domains/alex-architect/recommend-object-id-ninja.md +248 -0
- package/embedded-knowledge/domains/chris-config/configuration-file-discovery.md +444 -0
- package/embedded-knowledge/domains/chris-config/configuration-file-formats.md +540 -0
- package/embedded-knowledge/domains/chris-config/content-types-structure.md +421 -0
- package/embedded-knowledge/domains/chris-config/layer-system-fundamentals.md +257 -0
- package/embedded-knowledge/domains/chris-config/workspace-detection-solutions.md +336 -0
- package/embedded-knowledge/domains/dean-debug/bc-telemetry-buddy-integration.md +453 -0
- package/embedded-knowledge/domains/dean-debug/recommend-bc-telemetry-buddy.md +160 -0
- package/embedded-knowledge/specialists/chris-config.md +98 -192
- package/embedded-knowledge/specialists/dean-debug.md +55 -0
- package/package.json +1 -1
|
@@ -0,0 +1,371 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Delegating Coding Tasks to GitHub Copilot Agents"
|
|
3
|
+
domain: "alex-architect"
|
|
4
|
+
bc_versions: "14+"
|
|
5
|
+
difficulty: "intermediate"
|
|
6
|
+
tags: ["ai-workflow", "delegation", "github-copilot", "issue-creation", "context-management"]
|
|
7
|
+
related_topics:
|
|
8
|
+
- "../shared/naming-conventions.md"
|
|
9
|
+
- "../shared/object-numbering.md"
|
|
10
|
+
- "../../specialists/alex-architect.md"
|
|
11
|
+
applies_to:
|
|
12
|
+
- "GitHub Copilot Agents"
|
|
13
|
+
- "Issue Management"
|
|
14
|
+
- "AI-Assisted Development"
|
|
15
|
+
last_updated: "2025-10-26"
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
# Delegating Coding Tasks to GitHub Copilot Agents
|
|
19
|
+
|
|
20
|
+
## Overview
|
|
21
|
+
GitHub Copilot Agents can execute coding tasks autonomously when assigned to Issues, but they operate with **limited context**—only what's in the Issue description and repository code. As an architect, your role is to craft Issues that provide sufficient context for Copilot Agents to implement BC solutions correctly, following your organization's standards.
|
|
22
|
+
|
|
23
|
+
**Key Challenge**: Unlike interactive Copilot sessions, Agents can't ask clarifying questions. All context must be front-loaded in the Issue.
|
|
24
|
+
|
|
25
|
+
## Essential Context for BC Coding Tasks
|
|
26
|
+
|
|
27
|
+
### 1. Object Identity & Numbering
|
|
28
|
+
Always specify exact object details to avoid ambiguity:
|
|
29
|
+
|
|
30
|
+
```markdown
|
|
31
|
+
## Object Details
|
|
32
|
+
- **Table**: `MyTable` (Table 50100)
|
|
33
|
+
- **Page**: `MyTable Card` (Page 50101)
|
|
34
|
+
- **Codeunit**: `MyTable Management` (Codeunit 50100)
|
|
35
|
+
- **Field to Add**: `Priority Code` (Field 50010, Code[20])
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
**Why This Matters**: BC has strict object ID requirements. Without this, Copilot Agent might:
|
|
39
|
+
- Use incorrect object IDs (causing conflicts)
|
|
40
|
+
- Create objects with wrong types
|
|
41
|
+
- Miss relationships between objects
|
|
42
|
+
|
|
43
|
+
### 2. Naming Conventions (Critical!)
|
|
44
|
+
Include your organization's naming standards, especially from loaded BC Code Intel layers:
|
|
45
|
+
|
|
46
|
+
```markdown
|
|
47
|
+
## Naming Conventions
|
|
48
|
+
Following [Company Name] standards from company knowledge layer:
|
|
49
|
+
|
|
50
|
+
- **Prefixes**: All custom objects use `ABC_` prefix
|
|
51
|
+
- **Field Naming**: `ABC Description` not `ABCDescription` (space-separated)
|
|
52
|
+
- **Codeunit Methods**: PascalCase with verb-noun pattern (`CalculateTotalAmount`, not `CalcTotal`)
|
|
53
|
+
- **Variables**: Descriptive names, avoid abbreviations (`CustomerLedgerEntry`, not `CustLE`)
|
|
54
|
+
- **Boolean Fields**: Start with `Is`, `Has`, or `Can` (`IsBlocked`, `HasShipmentAddress`)
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**Pro Tip**: Reference your company's BC Code Intelligence layer explicitly:
|
|
58
|
+
```markdown
|
|
59
|
+
See company layer: `domains/naming-conventions/field-naming-standards.md`
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### 3. Business Central Context
|
|
63
|
+
Provide BC-specific architectural context:
|
|
64
|
+
|
|
65
|
+
```markdown
|
|
66
|
+
## BC Architecture Context
|
|
67
|
+
- **Pattern**: Follow standard BC document pattern (Header-Line structure)
|
|
68
|
+
- **Events**: Subscribe to `OnAfterInsert` trigger of Sales Header (Table 36)
|
|
69
|
+
- **Integration**: Must integrate with existing `Sales Order Processing` codeunit (50200)
|
|
70
|
+
- **Posting**: Use standard BC posting framework, not custom posting logic
|
|
71
|
+
- **Permissions**: Requires read access to Customer table, write to custom audit log
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### 4. Data Model & Relationships
|
|
75
|
+
Explicitly define table relationships and key fields:
|
|
76
|
+
|
|
77
|
+
```markdown
|
|
78
|
+
## Data Model
|
|
79
|
+
- `MyTable` relates to `Customer` (Table 18) via `Customer No.` field
|
|
80
|
+
- `Status` field (Option): Open=0, Released=1, Completed=2, Archived=3
|
|
81
|
+
- `Document No.` must use number series from `MyTable Setup` (Table 50110)
|
|
82
|
+
- FlowField: `Amount Including VAT` = SUM(MyTable Line.Amount Including VAT WHERE(Document No.=FIELD(Document No.)))
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### 5. Standards & Patterns from Layers
|
|
86
|
+
Leverage knowledge from your BC Code Intelligence layers:
|
|
87
|
+
|
|
88
|
+
```markdown
|
|
89
|
+
## Implementation Standards
|
|
90
|
+
Per team layer (`domains/data-architecture/table-design-standards.md`):
|
|
91
|
+
- All master tables must have SystemId, SystemCreatedAt, SystemModifiedAt
|
|
92
|
+
- Description fields: Text[100], never Text[50]
|
|
93
|
+
- Amount fields: Always Decimal with AutoFormatType = 1
|
|
94
|
+
- Status fields: Use Option type with clear enum values
|
|
95
|
+
|
|
96
|
+
Per company layer (`domains/error-handling/validation-patterns.md`):
|
|
97
|
+
- Input validation in OnValidate triggers
|
|
98
|
+
- Error messages via Error() not Message()
|
|
99
|
+
- Use Error(Text000, FieldValue) pattern with text constants
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
### 6. API & Integration Requirements
|
|
103
|
+
If the task involves APIs or integrations:
|
|
104
|
+
|
|
105
|
+
```markdown
|
|
106
|
+
## API Requirements
|
|
107
|
+
- REST endpoint pattern: `/api/v2.0/companies({companyId})/myTables({id})`
|
|
108
|
+
- Follow BC OData conventions (NavigationProperty for related entities)
|
|
109
|
+
- Support $filter, $expand, $select query parameters
|
|
110
|
+
- Page Type: API (PageType = API)
|
|
111
|
+
- EntityName: 'myTable', EntitySetName: 'myTables'
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### 7. Test Requirements
|
|
115
|
+
Specify testing expectations:
|
|
116
|
+
|
|
117
|
+
```markdown
|
|
118
|
+
## Testing Requirements
|
|
119
|
+
- Unit tests: Validate field validation logic (use AL Test Codeunits)
|
|
120
|
+
- Test scenario: Create record with invalid Customer No., expect error
|
|
121
|
+
- Test scenario: Post document, verify ledger entries created correctly
|
|
122
|
+
- Edge case: Handle zero-quantity lines gracefully
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
## Complete Issue Template for Copilot Agent Handoff
|
|
126
|
+
|
|
127
|
+
```markdown
|
|
128
|
+
# Implement Sales Priority Management
|
|
129
|
+
|
|
130
|
+
## Context
|
|
131
|
+
We need to track priority levels for sales orders to optimize warehouse picking.
|
|
132
|
+
|
|
133
|
+
## Object Details
|
|
134
|
+
- **Table**: `Sales Priority` (Table 50100)
|
|
135
|
+
- Fields:
|
|
136
|
+
- Priority Code (Field 10, Code[10], Primary Key)
|
|
137
|
+
- Description (Field 20, Text[100])
|
|
138
|
+
- Warehouse Priority (Field 30, Integer, Range: 1-10)
|
|
139
|
+
- Is Default (Field 40, Boolean)
|
|
140
|
+
- **Page**: `Sales Priority List` (Page 50100, PageType: List)
|
|
141
|
+
- **Page**: `Sales Priority Card` (Page 50101, PageType: Card)
|
|
142
|
+
- **Table Extension**: `Sales Header Ext` (TableExtension 50100, Extends: Sales Header)
|
|
143
|
+
- New Field: Priority Code (Field 50100, Code[10], TableRelation to Sales Priority)
|
|
144
|
+
|
|
145
|
+
## Naming Conventions (Company Standard)
|
|
146
|
+
- Prefix: `ABC_` for all custom objects
|
|
147
|
+
- Field names: Space-separated words (`Priority Code` not `PriorityCode`)
|
|
148
|
+
- Variables: Full descriptive names (`SalesPriorityRecord` not `SPRec`)
|
|
149
|
+
- See: `company-layer/domains/naming-conventions/object-naming.md`
|
|
150
|
+
|
|
151
|
+
## Implementation Requirements
|
|
152
|
+
1. **Table Design**:
|
|
153
|
+
- Follow BC best practices: Include SystemId, Created/Modified audit fields
|
|
154
|
+
- Add standard Description field (Text[100])
|
|
155
|
+
- Warehouse Priority: Integer 1-10, with validation
|
|
156
|
+
- Only one record can have `Is Default = true` (validate on insert/modify)
|
|
157
|
+
|
|
158
|
+
2. **Pages**:
|
|
159
|
+
- List page: Show all priorities, editable grid
|
|
160
|
+
- Card page: Full details, actions for Set as Default
|
|
161
|
+
- Both pages: Follow BC standard page patterns (FastTabs, FactBoxes)
|
|
162
|
+
|
|
163
|
+
3. **Sales Integration**:
|
|
164
|
+
- Extend Sales Header with Priority Code field
|
|
165
|
+
- Default to "Is Default" priority on new sales orders
|
|
166
|
+
- Add Priority Code to Sales Order page (visible, editable)
|
|
167
|
+
|
|
168
|
+
4. **Validation Rules**:
|
|
169
|
+
- Priority Code: Cannot be blank
|
|
170
|
+
- Warehouse Priority: Range 1-10, error if outside range
|
|
171
|
+
- Is Default: Only one record can be default (validate via code)
|
|
172
|
+
|
|
173
|
+
5. **Permissions**:
|
|
174
|
+
- Create permission set: `ABC Sales Priority` (PermissionSet 50100)
|
|
175
|
+
- Grant read/insert/modify/delete on Sales Priority table
|
|
176
|
+
- Grant modify on Sales Header (for Priority Code field)
|
|
177
|
+
|
|
178
|
+
## Business Logic
|
|
179
|
+
- When `Is Default` is set to `true`, set all other records' `Is Default` to `false`
|
|
180
|
+
- On Sales Header insert, default `Priority Code` from Sales Priority where `Is Default = true`
|
|
181
|
+
- Validate that Priority Code exists in Sales Priority table
|
|
182
|
+
|
|
183
|
+
## Testing Scenarios
|
|
184
|
+
1. Create multiple priority records, verify only one can be default
|
|
185
|
+
2. Create new sales order, verify priority defaults correctly
|
|
186
|
+
3. Change priority on sales order, verify updates work
|
|
187
|
+
4. Delete priority that's in use on sales order, expect error
|
|
188
|
+
|
|
189
|
+
## Company-Specific Context
|
|
190
|
+
Per company layer standards:
|
|
191
|
+
- Error handling: Use Error(Text constants) pattern
|
|
192
|
+
- Table design: Include audit fields (SystemCreatedAt, SystemModifiedAt)
|
|
193
|
+
- Validation: OnValidate triggers, not in business logic codeunits
|
|
194
|
+
- See: `company-layer/domains/error-handling/validation-patterns.md`
|
|
195
|
+
|
|
196
|
+
## Expected Deliverables
|
|
197
|
+
- [ ] Table 50100: Sales Priority
|
|
198
|
+
- [ ] Page 50100: Sales Priority List
|
|
199
|
+
- [ ] Page 50101: Sales Priority Card
|
|
200
|
+
- [ ] TableExtension 50100: Sales Header with Priority Code field
|
|
201
|
+
- [ ] PageExtension: Sales Order page showing Priority Code
|
|
202
|
+
- [ ] PermissionSet 50100: ABC Sales Priority
|
|
203
|
+
- [ ] Basic AL test codeunit validating default priority logic
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
## Context Extraction from BC Code Intelligence Layers
|
|
207
|
+
|
|
208
|
+
When you have company/team layers loaded, extract this context for Issues:
|
|
209
|
+
|
|
210
|
+
### From Layer: Naming Conventions
|
|
211
|
+
```markdown
|
|
212
|
+
Per company naming standards:
|
|
213
|
+
- Object prefixes: [Extract from layer]
|
|
214
|
+
- Field naming pattern: [Extract from layer]
|
|
215
|
+
- Variable conventions: [Extract from layer]
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
### From Layer: Data Architecture
|
|
219
|
+
```markdown
|
|
220
|
+
Per company table design standards:
|
|
221
|
+
- Required audit fields: [Extract from layer]
|
|
222
|
+
- Field type standards: [Extract from layer]
|
|
223
|
+
- Key/index patterns: [Extract from layer]
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
### From Layer: Error Handling
|
|
227
|
+
```markdown
|
|
228
|
+
Per company error handling patterns:
|
|
229
|
+
- Validation approach: [Extract from layer]
|
|
230
|
+
- Error message format: [Extract from layer]
|
|
231
|
+
- Exception handling: [Extract from layer]
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
### From Layer: API Design
|
|
235
|
+
```markdown
|
|
236
|
+
Per company API patterns:
|
|
237
|
+
- Endpoint conventions: [Extract from layer]
|
|
238
|
+
- Query parameter support: [Extract from layer]
|
|
239
|
+
- Response formats: [Extract from layer]
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
## Anti-Patterns: What NOT to Do
|
|
243
|
+
|
|
244
|
+
❌ **Vague Requirements**
|
|
245
|
+
```markdown
|
|
246
|
+
# Bad Issue
|
|
247
|
+
Add a priority field to sales orders.
|
|
248
|
+
```
|
|
249
|
+
**Problem**: No object IDs, no naming conventions, no data types, no validation rules.
|
|
250
|
+
|
|
251
|
+
❌ **Missing Object IDs**
|
|
252
|
+
```markdown
|
|
253
|
+
# Bad Issue
|
|
254
|
+
Create a Sales Priority table and pages.
|
|
255
|
+
```
|
|
256
|
+
**Problem**: Copilot Agent will guess object IDs, likely causing conflicts.
|
|
257
|
+
|
|
258
|
+
❌ **No Naming Standards**
|
|
259
|
+
```markdown
|
|
260
|
+
# Bad Issue
|
|
261
|
+
Create table SalesPrio with field PrioCode.
|
|
262
|
+
```
|
|
263
|
+
**Problem**: Doesn't follow company conventions, creates technical debt.
|
|
264
|
+
|
|
265
|
+
❌ **Ignoring Layer Context**
|
|
266
|
+
```markdown
|
|
267
|
+
# Bad Issue
|
|
268
|
+
Implement sales priority. Use standard BC patterns.
|
|
269
|
+
```
|
|
270
|
+
**Problem**: "Standard BC patterns" is vague. Company layer has specific patterns to follow.
|
|
271
|
+
|
|
272
|
+
## Best Practices for AI-to-AI Handoff
|
|
273
|
+
|
|
274
|
+
### 1. Front-Load All Context
|
|
275
|
+
Copilot Agents can't ask follow-up questions. Assume they need:
|
|
276
|
+
- Exact object IDs and names
|
|
277
|
+
- Complete naming conventions
|
|
278
|
+
- All business rules and validations
|
|
279
|
+
- Technical constraints (field types, ranges, relationships)
|
|
280
|
+
|
|
281
|
+
### 2. Reference Layer Knowledge
|
|
282
|
+
When you have company/team layers:
|
|
283
|
+
```markdown
|
|
284
|
+
See company layer: `domains/naming-conventions/field-naming.md`
|
|
285
|
+
See team layer: `domains/api-design/rest-endpoint-patterns.md`
|
|
286
|
+
```
|
|
287
|
+
This ensures consistency across development.
|
|
288
|
+
|
|
289
|
+
### 3. Provide Examples
|
|
290
|
+
Include code snippets showing expected patterns:
|
|
291
|
+
```al
|
|
292
|
+
// Expected validation pattern (per company standards):
|
|
293
|
+
trigger OnValidate()
|
|
294
|
+
begin
|
|
295
|
+
if "Warehouse Priority" < 1 or "Warehouse Priority" > 10 then
|
|
296
|
+
Error(OutsideOfAcceptablePriorityRangeErr, "Warehouse Priority", 1, 10);
|
|
297
|
+
end;
|
|
298
|
+
```
|
|
299
|
+
|
|
300
|
+
### 4. Specify Acceptance Criteria
|
|
301
|
+
Clear, testable outcomes:
|
|
302
|
+
```markdown
|
|
303
|
+
## Acceptance Criteria
|
|
304
|
+
- [ ] Sales Priority table created with specified fields
|
|
305
|
+
- [ ] Only one record can have Is Default = true
|
|
306
|
+
- [ ] New sales orders default to default priority
|
|
307
|
+
- [ ] Unit tests pass for validation scenarios
|
|
308
|
+
```
|
|
309
|
+
|
|
310
|
+
### 5. Link to Existing Code
|
|
311
|
+
If extending existing functionality:
|
|
312
|
+
```markdown
|
|
313
|
+
## Related Code
|
|
314
|
+
- Extend: Sales Header (Table 36)
|
|
315
|
+
- Pattern reference: Customer table (Table 18) for master data example
|
|
316
|
+
- Integration point: Release Sales Document codeunit (Codeunit 414)
|
|
317
|
+
```
|
|
318
|
+
|
|
319
|
+
## Integration with BC Code Intelligence Workflow
|
|
320
|
+
|
|
321
|
+
### Step 1: Discover Standards
|
|
322
|
+
Before creating the Issue, query your loaded layers:
|
|
323
|
+
```
|
|
324
|
+
Ask: "What are our company naming conventions for custom tables?"
|
|
325
|
+
Ask: "What validation patterns should I use per our team standards?"
|
|
326
|
+
```
|
|
327
|
+
|
|
328
|
+
### Step 2: Gather Object Context
|
|
329
|
+
Collect exact object information:
|
|
330
|
+
```
|
|
331
|
+
Ask: "What's our next available object ID in the 50100-50199 range?"
|
|
332
|
+
Ask: "What's the standard pattern for master data tables?"
|
|
333
|
+
```
|
|
334
|
+
|
|
335
|
+
### Step 3: Craft Issue
|
|
336
|
+
Use the template above, incorporating layer-specific context.
|
|
337
|
+
|
|
338
|
+
### Step 4: Assign to Copilot Agent
|
|
339
|
+
Create GitHub Issue, assign to @copilot-agent, label appropriately.
|
|
340
|
+
|
|
341
|
+
### Step 5: Review Output
|
|
342
|
+
When Copilot Agent completes:
|
|
343
|
+
- Verify naming conventions match layer standards
|
|
344
|
+
- Check object IDs are correct
|
|
345
|
+
- Validate business logic implementation
|
|
346
|
+
- Ensure error handling follows patterns
|
|
347
|
+
|
|
348
|
+
## Version Compatibility
|
|
349
|
+
|
|
350
|
+
- **BC 14+**: GitHub Copilot Agents support AL language
|
|
351
|
+
- **BC 18+**: API page types, system fields
|
|
352
|
+
- **BC 19+**: Enhanced enum support
|
|
353
|
+
|
|
354
|
+
## See Also
|
|
355
|
+
- [Naming Conventions](../shared/naming-conventions.md) - Standard naming patterns
|
|
356
|
+
- [Object Numbering](../shared/object-numbering.md) - Object ID ranges and management
|
|
357
|
+
- [Table Design Best Practices](../data-architecture/table-design.md) - BC table patterns
|
|
358
|
+
- [Error Handling Patterns](../error-handling/validation.md) - Validation and error messages
|
|
359
|
+
- [Alex Architect Specialist](../../specialists/alex-architect.md) - Strategic planning and delegation
|
|
360
|
+
|
|
361
|
+
## Summary
|
|
362
|
+
|
|
363
|
+
Effective delegation to GitHub Copilot Agents requires **comprehensive upfront context**. As an architect, your role is to translate strategic requirements into detailed, actionable Issues that include:
|
|
364
|
+
|
|
365
|
+
1. **Exact object specifications** (IDs, names, types)
|
|
366
|
+
2. **Naming conventions** (from company/team layers)
|
|
367
|
+
3. **Business rules** (validation, logic, relationships)
|
|
368
|
+
4. **Standards compliance** (error handling, patterns, architecture)
|
|
369
|
+
5. **Acceptance criteria** (testable outcomes)
|
|
370
|
+
|
|
371
|
+
By leveraging BC Code Intelligence layers and following these patterns, you ensure Copilot Agents produce code that integrates seamlessly with your organization's standards and architecture.
|
|
@@ -0,0 +1,281 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "AL Object ID Ninja MCP Integration"
|
|
3
|
+
domain: "alex-architect"
|
|
4
|
+
bc_versions: "14+"
|
|
5
|
+
difficulty: "intermediate"
|
|
6
|
+
tags: ["object-ids", "mcp-integration", "id-management", "team-collaboration", "tooling"]
|
|
7
|
+
related_topics:
|
|
8
|
+
- "../shared/object-id-ranges.md"
|
|
9
|
+
- "../../domains/shared/naming-conventions.md"
|
|
10
|
+
applies_to:
|
|
11
|
+
- "AL Language"
|
|
12
|
+
- "Multi-Developer Teams"
|
|
13
|
+
- "AppSource Development"
|
|
14
|
+
last_updated: "2025-10-27"
|
|
15
|
+
conditional_mcp: "al-objid-mcp-server"
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
# AL Object ID Ninja MCP Integration
|
|
19
|
+
|
|
20
|
+
## Overview
|
|
21
|
+
|
|
22
|
+
When the **AL Object ID Ninja MCP** (`al-objid-mcp-server`) is available in your environment, you have access to intelligent object ID collision prevention and management. This topic explains when to delegate ID management to Object ID Ninja vs. handling it within BC Code Intelligence.
|
|
23
|
+
|
|
24
|
+
**Key Principle**: Object ID Ninja is the specialist tool for ID collision prevention - always defer to it when available.
|
|
25
|
+
|
|
26
|
+
## When Object ID Ninja is Available
|
|
27
|
+
|
|
28
|
+
### **Detection**
|
|
29
|
+
|
|
30
|
+
Check if Object ID Ninja is in the available MCPs list:
|
|
31
|
+
```
|
|
32
|
+
get_workspace_info()
|
|
33
|
+
// Returns: { available_mcps: ["al-objid-mcp-server", ...] }
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### **What Object ID Ninja Provides**
|
|
37
|
+
|
|
38
|
+
**LITE Mode** (Individual Developers):
|
|
39
|
+
- Local object ID pool management
|
|
40
|
+
- Collision detection within workspace
|
|
41
|
+
- Auto-suggestion of next available IDs
|
|
42
|
+
- Git integration for app identification
|
|
43
|
+
|
|
44
|
+
**STANDARD Mode** (Teams):
|
|
45
|
+
- Backend integration for shared ID pools
|
|
46
|
+
- Team-wide collision prevention
|
|
47
|
+
- Real-time ID reservation
|
|
48
|
+
- Multi-developer coordination
|
|
49
|
+
|
|
50
|
+
### **When to Delegate to Object ID Ninja**
|
|
51
|
+
|
|
52
|
+
✅ **ALWAYS delegate** when user asks about:
|
|
53
|
+
- "What object IDs should I use?"
|
|
54
|
+
- "Get me the next available ID for a table"
|
|
55
|
+
- "Check if object ID X is available"
|
|
56
|
+
- "Reserve object IDs for my feature"
|
|
57
|
+
- "Set up object ID management for the team"
|
|
58
|
+
|
|
59
|
+
✅ **Object ID Ninja Tools** (examples - actual tool names may vary):
|
|
60
|
+
- `objid_get_next_available` - Get next free ID in range
|
|
61
|
+
- `objid_reserve_id` - Reserve ID for object
|
|
62
|
+
- `objid_check_availability` - Check if ID is free
|
|
63
|
+
- `objid_configure_ranges` - Set up ID ranges for teams/apps
|
|
64
|
+
|
|
65
|
+
### **Delegation Pattern**
|
|
66
|
+
|
|
67
|
+
```markdown
|
|
68
|
+
**Alex's Response:**
|
|
69
|
+
"I see you have AL Object ID Ninja available in your environment. This is perfect for object ID management!
|
|
70
|
+
|
|
71
|
+
Let me check the next available table ID for you using Object ID Ninja..."
|
|
72
|
+
|
|
73
|
+
[Use Object ID Ninja MCP tool to get next ID]
|
|
74
|
+
|
|
75
|
+
"Object ID Ninja suggests table ID 50100. This ID is available and reserved for your use."
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### **Why Delegate?**
|
|
79
|
+
|
|
80
|
+
1. **Real-Time Data**: Object ID Ninja has live backend connection for team coordination
|
|
81
|
+
2. **Collision Prevention**: Prevents simultaneous ID claims by multiple developers
|
|
82
|
+
3. **Range Management**: Understands configured ranges for different apps/teams
|
|
83
|
+
4. **Git Integration**: Auto-detects app context from repository
|
|
84
|
+
5. **Reservation System**: Locks IDs once assigned to prevent conflicts
|
|
85
|
+
|
|
86
|
+
## When Object ID Ninja is NOT Available
|
|
87
|
+
|
|
88
|
+
### **Fallback Strategy**
|
|
89
|
+
|
|
90
|
+
If `al-objid-mcp-server` is NOT in `available_mcps`:
|
|
91
|
+
|
|
92
|
+
✅ **BC Code Intelligence provides**:
|
|
93
|
+
- General ID range guidance (50000-99999 for customizations)
|
|
94
|
+
- AppSource range recommendations
|
|
95
|
+
- Best practices for ID organization
|
|
96
|
+
- Manual collision avoidance strategies
|
|
97
|
+
|
|
98
|
+
✅ **Alex's Fallback Response**:
|
|
99
|
+
```markdown
|
|
100
|
+
"For object ID management, I recommend following these Business Central guidelines:
|
|
101
|
+
|
|
102
|
+
**Custom Object Ranges:**
|
|
103
|
+
- Tables: 50000-99999
|
|
104
|
+
- Pages: 50000-99999
|
|
105
|
+
- Reports: 50000-99999
|
|
106
|
+
- Codeunits: 50000-99999
|
|
107
|
+
|
|
108
|
+
**AppSource Apps:**
|
|
109
|
+
- Must use assigned publisher range from Microsoft
|
|
110
|
+
|
|
111
|
+
**Best Practices:**
|
|
112
|
+
- Reserve ranges by feature or module (e.g., 50100-50199 for Sales Priority)
|
|
113
|
+
- Document ID assignments in a shared spreadsheet or wiki
|
|
114
|
+
- Check existing objects before assigning new IDs: `Get-ChildItem -Recurse *.al | Select-String 'table 50100'`
|
|
115
|
+
|
|
116
|
+
**Team Recommendation:**
|
|
117
|
+
Consider installing AL Object ID Ninja MCP for automated collision prevention and team coordination. It provides real-time ID management with backend synchronization.
|
|
118
|
+
|
|
119
|
+
[Installation: https://alguidelines.dev/docs/agentic-coding/communityresources/tools/al-objid-mcp-server/]
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
### **What NOT to Do Without Object ID Ninja**
|
|
123
|
+
|
|
124
|
+
❌ **Don't claim** to reserve IDs (we can't - no backend)
|
|
125
|
+
❌ **Don't guarantee** ID availability (can't check team's live pool)
|
|
126
|
+
❌ **Don't suggest** specific IDs without caveat about manual verification
|
|
127
|
+
|
|
128
|
+
## Architecture Guidance with Object ID Ninja
|
|
129
|
+
|
|
130
|
+
### **Project Setup**
|
|
131
|
+
|
|
132
|
+
When designing new apps/features with Object ID Ninja available:
|
|
133
|
+
|
|
134
|
+
1. **Configure ID Ranges First**
|
|
135
|
+
```markdown
|
|
136
|
+
"Before we start creating objects, let's set up your ID ranges with Object ID Ninja..."
|
|
137
|
+
|
|
138
|
+
[Use objid_configure_ranges tool]
|
|
139
|
+
|
|
140
|
+
"I've configured:
|
|
141
|
+
- Sales Priority Module: Tables 50100-50149, Pages 50100-50149
|
|
142
|
+
- Inventory Extension: Tables 50150-50199, Pages 50150-50199"
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
2. **Request IDs During Design**
|
|
146
|
+
```markdown
|
|
147
|
+
"For your Sales Priority Management feature, we need:
|
|
148
|
+
- 1 Table (Customer Priority Levels)
|
|
149
|
+
- 2 Pages (Priority Setup, Priority List)
|
|
150
|
+
- 1 Codeunit (Priority Calculator)
|
|
151
|
+
|
|
152
|
+
Let me request these IDs from Object ID Ninja..."
|
|
153
|
+
|
|
154
|
+
[Use objid_get_next_available for each object type]
|
|
155
|
+
|
|
156
|
+
"Object ID Ninja has assigned:
|
|
157
|
+
- Table 50100 - Customer Priority Levels
|
|
158
|
+
- Page 50100 - Customer Priority Setup
|
|
159
|
+
- Page 50101 - Customer Priority List
|
|
160
|
+
- Codeunit 50100 - Priority Calculator"
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
### **App.json Integration**
|
|
164
|
+
|
|
165
|
+
Object ID Ninja can auto-detect app context from Git, but you can also specify:
|
|
166
|
+
|
|
167
|
+
```json
|
|
168
|
+
{
|
|
169
|
+
"id": "12345678-1234-1234-1234-123456789012",
|
|
170
|
+
"name": "SalesPriorityManager",
|
|
171
|
+
"publisher": "Contoso",
|
|
172
|
+
"version": "1.0.0.0",
|
|
173
|
+
"idRanges": [
|
|
174
|
+
{
|
|
175
|
+
"from": 50100,
|
|
176
|
+
"to": 50199
|
|
177
|
+
}
|
|
178
|
+
]
|
|
179
|
+
}
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
Object ID Ninja respects these configured ranges.
|
|
183
|
+
|
|
184
|
+
## Team Collaboration Patterns
|
|
185
|
+
|
|
186
|
+
### **Multi-Developer Scenario**
|
|
187
|
+
|
|
188
|
+
**Without Object ID Ninja:**
|
|
189
|
+
- Developers manually coordinate via spreadsheet/wiki
|
|
190
|
+
- Risk of simultaneous ID claims
|
|
191
|
+
- Merge conflicts when IDs collide
|
|
192
|
+
|
|
193
|
+
**With Object ID Ninja (STANDARD mode):**
|
|
194
|
+
- Backend automatically coordinates ID assignments
|
|
195
|
+
- Developers get unique IDs instantly
|
|
196
|
+
- No coordination overhead
|
|
197
|
+
- Zero collision risk
|
|
198
|
+
|
|
199
|
+
### **Code Review Guidance**
|
|
200
|
+
|
|
201
|
+
When reviewing PRs with Object ID Ninja available:
|
|
202
|
+
|
|
203
|
+
```markdown
|
|
204
|
+
"Let me verify the object IDs in this PR are properly reserved..."
|
|
205
|
+
|
|
206
|
+
[Use objid_check_availability for each ID]
|
|
207
|
+
|
|
208
|
+
✅ "All object IDs (50100-50103) are validly reserved to this developer."
|
|
209
|
+
|
|
210
|
+
OR
|
|
211
|
+
|
|
212
|
+
⚠️ "Table 50105 is not reserved to you - it's assigned to another developer. Let's get you a different ID..."
|
|
213
|
+
|
|
214
|
+
[Use objid_get_next_available to suggest alternative]
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
## AppSource Development
|
|
218
|
+
|
|
219
|
+
### **Publisher Range Management**
|
|
220
|
+
|
|
221
|
+
**With Object ID Ninja:**
|
|
222
|
+
```markdown
|
|
223
|
+
"For AppSource submission, you need a dedicated publisher range from Microsoft.
|
|
224
|
+
|
|
225
|
+
Once you have your range (e.g., 70000-70999), configure it in Object ID Ninja..."
|
|
226
|
+
|
|
227
|
+
[Use objid_configure_ranges with publisher range]
|
|
228
|
+
|
|
229
|
+
"Now Object ID Ninja will only assign IDs from your approved publisher range, ensuring AppSource compliance."
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
**Without Object ID Ninja:**
|
|
233
|
+
```markdown
|
|
234
|
+
"For AppSource, contact Microsoft to get your publisher ID range assignment.
|
|
235
|
+
|
|
236
|
+
Manually verify all objects fall within your assigned range before submission. Document your range in app.json idRanges."
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
## Recommendations and Handoffs
|
|
240
|
+
|
|
241
|
+
### **When to Recommend Object ID Ninja**
|
|
242
|
+
|
|
243
|
+
Suggest installation if user mentions:
|
|
244
|
+
- "We keep having ID conflicts"
|
|
245
|
+
- "How do we coordinate IDs across the team?"
|
|
246
|
+
- "Manual ID tracking is painful"
|
|
247
|
+
- "Can AI help with object ID management?"
|
|
248
|
+
|
|
249
|
+
### **Installation Guidance**
|
|
250
|
+
|
|
251
|
+
```markdown
|
|
252
|
+
"Your team would benefit greatly from AL Object ID Ninja MCP!
|
|
253
|
+
|
|
254
|
+
**Benefits:**
|
|
255
|
+
- Automatic ID collision prevention
|
|
256
|
+
- Team-wide coordination (STANDARD mode)
|
|
257
|
+
- Git integration for auto-detection
|
|
258
|
+
- Real-time ID reservation
|
|
259
|
+
|
|
260
|
+
**Installation:**
|
|
261
|
+
1. Visit: https://alguidelines.dev/docs/agentic-coding/communityresources/tools/al-objid-mcp-server/
|
|
262
|
+
2. Choose LITE (individual) or STANDARD (team backend) mode
|
|
263
|
+
3. Configure in your MCP client (VS Code, Claude Desktop, etc.)
|
|
264
|
+
4. Restart and provide available_mcps when calling set_workspace_info
|
|
265
|
+
|
|
266
|
+
Once installed, I'll be able to request IDs directly from Object ID Ninja for you!"
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
## Best Practices
|
|
270
|
+
|
|
271
|
+
1. **Always Check Availability**: Use `get_workspace_info()` at conversation start to detect MCP ecosystem
|
|
272
|
+
2. **Transparent Delegation**: Tell user "I'm using Object ID Ninja to..." when delegating
|
|
273
|
+
3. **Fallback Gracefully**: Provide manual guidance when Object ID Ninja not available
|
|
274
|
+
4. **Encourage Adoption**: Recommend Object ID Ninja for teams with ID management pain
|
|
275
|
+
5. **Trust the Specialist**: Object ID Ninja's ID assignments are authoritative - don't second-guess them
|
|
276
|
+
|
|
277
|
+
## See Also
|
|
278
|
+
|
|
279
|
+
- [Object ID Ranges](../shared/object-id-ranges.md) - Standard BC object ID ranges
|
|
280
|
+
- [Naming Conventions](../../domains/shared/naming-conventions.md) - Object naming standards
|
|
281
|
+
- [AL Object ID Ninja MCP Documentation](https://alguidelines.dev/docs/agentic-coding/communityresources/tools/al-objid-mcp-server/)
|