mcp-quickbase 2.1.0 → 2.2.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/.sdd/tickets/RELS_relationship-management/README.md +98 -0
- package/.sdd/tickets/RELS_relationship-management/planning/analysis.md +190 -0
- package/.sdd/tickets/RELS_relationship-management/planning/architecture.md +413 -0
- package/.sdd/tickets/RELS_relationship-management/planning/plan.md +177 -0
- package/.sdd/tickets/RELS_relationship-management/planning/quality-strategy.md +335 -0
- package/.sdd/tickets/RELS_relationship-management/planning/review-updates.md +95 -0
- package/.sdd/tickets/RELS_relationship-management/planning/security-review.md +213 -0
- package/.sdd/tickets/RELS_relationship-management/planning/ticket-review.md +885 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.1001_domain-setup.md +96 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.1002_get-relationships-tool.md +142 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.1003_register-phase1-tools.md +105 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.2001_create-relationship-tool.md +151 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.2002_update-relationship-tool.md +145 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.3001_delete-relationship-tool.md +154 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.4001_integration-testing.md +159 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS.4002_final-verification.md +182 -0
- package/.sdd/tickets/RELS_relationship-management/tasks/RELS_TASK_INDEX.md +179 -0
- package/dist/tools/apps/list_tables.d.ts +5 -5
- package/dist/tools/apps/list_tables.js +1 -1
- package/dist/tools/index.d.ts +1 -0
- package/dist/tools/index.js +4 -1
- package/dist/tools/index.js.map +1 -1
- package/dist/tools/relationships/create_relationship.d.ts +150 -0
- package/dist/tools/relationships/create_relationship.js +181 -0
- package/dist/tools/relationships/create_relationship.js.map +1 -0
- package/dist/tools/relationships/delete_relationship.d.ts +66 -0
- package/dist/tools/relationships/delete_relationship.js +85 -0
- package/dist/tools/relationships/delete_relationship.js.map +1 -0
- package/dist/tools/relationships/get_relationships.d.ts +126 -0
- package/dist/tools/relationships/get_relationships.js +126 -0
- package/dist/tools/relationships/get_relationships.js.map +1 -0
- package/dist/tools/relationships/index.d.ts +14 -0
- package/dist/tools/relationships/index.js +37 -0
- package/dist/tools/relationships/index.js.map +1 -0
- package/dist/tools/relationships/update_relationship.d.ts +139 -0
- package/dist/tools/relationships/update_relationship.js +168 -0
- package/dist/tools/relationships/update_relationship.js.map +1 -0
- package/package.json +1 -1
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
# Task: [RELS.1001]: Domain Setup and Directory Structure
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
- [x] **Task completed** - acceptance criteria met
|
|
5
|
+
- [x] **Tests pass** - tests executed and passing (or N/A if no tests)
|
|
6
|
+
- [x] **Verified** - by the verify-task agent
|
|
7
|
+
|
|
8
|
+
**Note on "Tests pass"**:
|
|
9
|
+
- If tests were created/modified, you MUST run them and show output
|
|
10
|
+
- "Tests pass" means tests were EXECUTED and all passed
|
|
11
|
+
- "Tests pass - N/A" is only valid for documentation-only tickets
|
|
12
|
+
- Test file existence alone does NOT satisfy this requirement
|
|
13
|
+
|
|
14
|
+
## Agents
|
|
15
|
+
- implement-feature
|
|
16
|
+
- unit-test-runner
|
|
17
|
+
- verify-task
|
|
18
|
+
- commit-task
|
|
19
|
+
|
|
20
|
+
## Summary
|
|
21
|
+
Create the relationships domain directory structure and registration pattern following the existing codebase patterns for domains like tables, fields, and records.
|
|
22
|
+
|
|
23
|
+
## Background
|
|
24
|
+
This is the foundation task for the relationship management feature. The MCP Quickbase server organizes tools into domain-specific directories (apps, tables, fields, records, etc.). This task establishes the relationships domain structure and registration pattern that all subsequent relationship tools will use.
|
|
25
|
+
|
|
26
|
+
This implements Phase 1 foundation work from plan.md.
|
|
27
|
+
|
|
28
|
+
## Acceptance Criteria
|
|
29
|
+
- [x] Directory `src/tools/relationships/` exists
|
|
30
|
+
- [x] File `src/tools/relationships/index.ts` exists with `registerRelationshipTools()` function
|
|
31
|
+
- [x] Registration function accepts `QuickbaseClient` parameter
|
|
32
|
+
- [x] Registration pattern follows existing domain patterns (see `src/tools/fields/index.ts` or `src/tools/tables/index.ts`)
|
|
33
|
+
- [x] Exports are structured for future tool additions
|
|
34
|
+
- [x] File structure validated by TypeScript compilation (`npm run build` succeeds)
|
|
35
|
+
|
|
36
|
+
## Technical Requirements
|
|
37
|
+
- Follow existing domain registration pattern from other tool directories
|
|
38
|
+
- Use TypeScript with strict type checking
|
|
39
|
+
- Export a `registerRelationshipTools(client: QuickbaseClient)` function
|
|
40
|
+
- Prepare for 4 tools: get_relationships, create_relationship, update_relationship, delete_relationship
|
|
41
|
+
- No actual tool implementations yet - this is structure only
|
|
42
|
+
|
|
43
|
+
## Implementation Notes
|
|
44
|
+
Study existing patterns:
|
|
45
|
+
- `src/tools/fields/index.ts` - Shows registration pattern with toolRegistry
|
|
46
|
+
- `src/tools/tables/index.ts` - Shows how to organize domain exports
|
|
47
|
+
|
|
48
|
+
Pattern to follow:
|
|
49
|
+
```typescript
|
|
50
|
+
import { QuickbaseClient } from '../../client/quickbase';
|
|
51
|
+
import { toolRegistry } from '../registry';
|
|
52
|
+
|
|
53
|
+
export function registerRelationshipTools(client: QuickbaseClient): void {
|
|
54
|
+
// Tools will be registered here in subsequent tasks
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
// Future exports
|
|
58
|
+
// export { GetRelationshipsTool } from './get_relationships';
|
|
59
|
+
// export { CreateRelationshipTool } from './create_relationship';
|
|
60
|
+
// export { UpdateRelationshipTool } from './update_relationship';
|
|
61
|
+
// export { DeleteRelationshipTool } from './delete_relationship';
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
## Dependencies
|
|
65
|
+
- None - this is the first task in the sequence
|
|
66
|
+
- Existing infrastructure: BaseTool, QuickbaseClient, toolRegistry
|
|
67
|
+
|
|
68
|
+
## Risk Assessment
|
|
69
|
+
- **Risk**: Directory structure doesn't match existing patterns
|
|
70
|
+
- **Mitigation**: Study at least 2 existing domain directories before implementing
|
|
71
|
+
- **Risk**: Registration function signature incompatible with main tools/index.ts
|
|
72
|
+
- **Mitigation**: Review how other domains are registered in src/tools/index.ts
|
|
73
|
+
|
|
74
|
+
## Files/Packages Affected
|
|
75
|
+
- src/tools/relationships/ (new directory)
|
|
76
|
+
- src/tools/relationships/index.ts (new file)
|
|
77
|
+
|
|
78
|
+
## Deliverables Produced
|
|
79
|
+
|
|
80
|
+
Documents created in `deliverables/` directory:
|
|
81
|
+
|
|
82
|
+
- None
|
|
83
|
+
|
|
84
|
+
## Verification Notes
|
|
85
|
+
Verify-task agent should confirm:
|
|
86
|
+
- Directory structure matches existing domain patterns
|
|
87
|
+
- index.ts compiles without errors
|
|
88
|
+
- Registration function signature is correct
|
|
89
|
+
- No actual tools registered yet (that happens in subsequent tasks)
|
|
90
|
+
- Code follows existing naming conventions (snake_case for tools, camelCase for functions)
|
|
91
|
+
|
|
92
|
+
## Verification Audit
|
|
93
|
+
<!-- Audit log maintained by verify-task agent for enterprise compliance -->
|
|
94
|
+
| Date | Agent | Decision | Notes |
|
|
95
|
+
|------|-------|----------|-------|
|
|
96
|
+
| 2025-12-28 | verify-task | PASS | All 6 acceptance criteria met, TypeScript compilation successful, tests passing (86/86), no .sdd references in production code |
|
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
# Task: [RELS.1002]: Implement GetRelationshipsTool
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
- [x] **Task completed** - acceptance criteria met
|
|
5
|
+
- [x] **Tests pass** - tests executed and passing (or N/A if no tests)
|
|
6
|
+
- [x] **Verified** - by the verify-task agent
|
|
7
|
+
|
|
8
|
+
**Note on "Tests pass"**:
|
|
9
|
+
- If tests were created/modified, you MUST run them and show output
|
|
10
|
+
- "Tests pass" means tests were EXECUTED and all passed
|
|
11
|
+
- "Tests pass - N/A" is only valid for documentation-only tickets
|
|
12
|
+
- Test file existence alone does NOT satisfy this requirement
|
|
13
|
+
|
|
14
|
+
## Agents
|
|
15
|
+
- implement-feature
|
|
16
|
+
- unit-test-runner
|
|
17
|
+
- verify-task
|
|
18
|
+
- commit-task
|
|
19
|
+
|
|
20
|
+
## Summary
|
|
21
|
+
Implement the `get_relationships` tool to query all table-to-table relationships for a given table, including support for pagination and complete relationship metadata.
|
|
22
|
+
|
|
23
|
+
## Background
|
|
24
|
+
This is the first read-only relationship tool, enabling agents to safely explore table structures and understand data connections. It's critical to validate the actual Quickbase API response structure before proceeding to write operations in Phase 2.
|
|
25
|
+
|
|
26
|
+
This implements Phase 1 from plan.md: Foundation - Read Operations.
|
|
27
|
+
|
|
28
|
+
## Acceptance Criteria
|
|
29
|
+
- [x] Tool name is `get_relationships` (snake_case)
|
|
30
|
+
- [x] Tool extends BaseTool with proper TypeScript types
|
|
31
|
+
- [x] Returns relationship structure with foreignKeyField, lookupFields, summaryFields
|
|
32
|
+
- [x] Pagination support via skip parameter works correctly
|
|
33
|
+
- [x] API response structure validated against TypeScript interfaces
|
|
34
|
+
- [x] Tool description clearly explains what information is returned
|
|
35
|
+
- [x] Tool registered in relationships/index.ts
|
|
36
|
+
- [x] Unit tests cover: success case, empty results, pagination, API errors
|
|
37
|
+
- [x] All tests pass with `npm test`
|
|
38
|
+
|
|
39
|
+
## Technical Requirements
|
|
40
|
+
- Endpoint: GET `/tables/{tableId}/relationships`
|
|
41
|
+
- Query parameters: skip (optional, for pagination)
|
|
42
|
+
- Response includes both parent and child relationships
|
|
43
|
+
- Return metadata: totalRelationships, numRelationships, skip
|
|
44
|
+
- Use QuickbaseClient.request() method for API calls
|
|
45
|
+
- Follow BaseTool pattern from existing tools
|
|
46
|
+
- TypeScript interfaces for GetRelationshipsParams and GetRelationshipsResult
|
|
47
|
+
|
|
48
|
+
## Implementation Notes
|
|
49
|
+
From architecture.md:
|
|
50
|
+
|
|
51
|
+
```typescript
|
|
52
|
+
interface GetRelationshipsParams {
|
|
53
|
+
table_id: string; // Required: Child table ID (DBID)
|
|
54
|
+
skip?: number; // Optional: Pagination offset
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
interface GetRelationshipsResult {
|
|
58
|
+
relationships: Relationship[];
|
|
59
|
+
metadata: {
|
|
60
|
+
totalRelationships: number;
|
|
61
|
+
numRelationships: number;
|
|
62
|
+
skip: number;
|
|
63
|
+
};
|
|
64
|
+
}
|
|
65
|
+
|
|
66
|
+
interface Relationship {
|
|
67
|
+
id: number;
|
|
68
|
+
parentTableId: string;
|
|
69
|
+
childTableId: string;
|
|
70
|
+
foreignKeyField: FieldInfo;
|
|
71
|
+
isCrossApp: boolean;
|
|
72
|
+
lookupFields: FieldInfo[];
|
|
73
|
+
summaryFields: FieldInfo[];
|
|
74
|
+
}
|
|
75
|
+
|
|
76
|
+
interface FieldInfo {
|
|
77
|
+
id: number;
|
|
78
|
+
label: string;
|
|
79
|
+
type: string;
|
|
80
|
+
}
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Tool description format (from architecture.md):
|
|
84
|
+
```
|
|
85
|
+
Gets all table-to-table relationships for a specified table. Returns both relationships
|
|
86
|
+
where this table is the child (has reference fields pointing to parents) and where this
|
|
87
|
+
table is the parent (has child tables referencing it). Use this tool to explore table
|
|
88
|
+
structure and understand data connections before modifying relationships.
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Use logging pattern:
|
|
92
|
+
```typescript
|
|
93
|
+
const logger = createLogger('GetRelationshipsTool');
|
|
94
|
+
logger.info('Getting relationships for table', { tableId });
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
## Dependencies
|
|
98
|
+
- RELS.1001 - Domain setup must be complete
|
|
99
|
+
- Existing: BaseTool, QuickbaseClient, toolRegistry
|
|
100
|
+
|
|
101
|
+
## Risk Assessment
|
|
102
|
+
- **Risk**: API response structure differs from documentation
|
|
103
|
+
- **Mitigation**: Add logging to inspect actual responses; adjust interfaces as needed
|
|
104
|
+
- **Risk**: Pagination parameter not supported by API
|
|
105
|
+
- **Mitigation**: Test with skip parameter; verify behavior matches expectations
|
|
106
|
+
- **Risk**: Cross-app relationships have different structure
|
|
107
|
+
- **Mitigation**: Include isCrossApp flag and handle limited details appropriately
|
|
108
|
+
|
|
109
|
+
## Files/Packages Affected
|
|
110
|
+
- src/tools/relationships/get_relationships.ts (new file)
|
|
111
|
+
- src/tools/relationships/index.ts (update exports and registration)
|
|
112
|
+
- src/__tests__/tools/relationships.test.ts (new file)
|
|
113
|
+
|
|
114
|
+
## Deliverables Produced
|
|
115
|
+
|
|
116
|
+
Documents created in `deliverables/` directory:
|
|
117
|
+
|
|
118
|
+
- None
|
|
119
|
+
|
|
120
|
+
## Verification Notes
|
|
121
|
+
Verify-task agent should confirm:
|
|
122
|
+
- Tool name follows snake_case convention
|
|
123
|
+
- TypeScript interfaces match API response structure
|
|
124
|
+
- API response structure is validated before Phase 2 proceeds (critical!)
|
|
125
|
+
- Pagination works as expected
|
|
126
|
+
- Error messages include table ID context for debugging
|
|
127
|
+
- Tests cover all critical paths from quality-strategy.md:
|
|
128
|
+
- Returns array of relationships with complete structure
|
|
129
|
+
- Pagination works (skip parameter honored)
|
|
130
|
+
- Empty array returned for tables with no relationships
|
|
131
|
+
- Table not found (404)
|
|
132
|
+
- Unauthorized (401)
|
|
133
|
+
- Forbidden (403)
|
|
134
|
+
- Network error
|
|
135
|
+
- Table with many relationships
|
|
136
|
+
- Cross-app relationships handled
|
|
137
|
+
|
|
138
|
+
## Verification Audit
|
|
139
|
+
<!-- Audit log maintained by verify-task agent for enterprise compliance -->
|
|
140
|
+
| Date | Agent | Decision | Notes |
|
|
141
|
+
|------|-------|----------|-------|
|
|
142
|
+
| 2025-12-28 | verify-task | PASS | All 9 acceptance criteria met, 100 tests passing, 100% coverage on get_relationships.ts |
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
# Task: [RELS.1003]: Register Relationship Tools in Main Index
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
- [x] **Task completed** - acceptance criteria met
|
|
5
|
+
- [x] **Tests pass** - tests executed and passing (or N/A if no tests)
|
|
6
|
+
- [x] **Verified** - by the verify-task agent
|
|
7
|
+
|
|
8
|
+
**Note on "Tests pass"**:
|
|
9
|
+
- If tests were created/modified, you MUST run them and show output
|
|
10
|
+
- "Tests pass" means tests were EXECUTED and all passed
|
|
11
|
+
- "Tests pass - N/A" is only valid for documentation-only tickets
|
|
12
|
+
- Test file existence alone does NOT satisfy this requirement
|
|
13
|
+
|
|
14
|
+
## Agents
|
|
15
|
+
- implement-feature
|
|
16
|
+
- unit-test-runner
|
|
17
|
+
- verify-task
|
|
18
|
+
- commit-task
|
|
19
|
+
|
|
20
|
+
## Summary
|
|
21
|
+
Update the main tools index to register relationship tools, making them accessible through the MCP server.
|
|
22
|
+
|
|
23
|
+
## Background
|
|
24
|
+
The relationship tools are implemented but need to be registered in the main tools/index.ts file so they appear in the tool registry and can be called by agents through the MCP interface.
|
|
25
|
+
|
|
26
|
+
This completes Phase 1 integration from plan.md.
|
|
27
|
+
|
|
28
|
+
## Acceptance Criteria
|
|
29
|
+
- [x] `src/tools/index.ts` imports `registerRelationshipTools` from relationships domain
|
|
30
|
+
- [x] Registration function called in `initializeTools()`
|
|
31
|
+
- [x] Relationship tools exported from main index for external use
|
|
32
|
+
- [x] TypeScript compilation succeeds (`npm run build`)
|
|
33
|
+
- [x] Integration test confirms tools appear in toolRegistry
|
|
34
|
+
- [x] `get_relationships` tool is callable through MCP
|
|
35
|
+
|
|
36
|
+
## Technical Requirements
|
|
37
|
+
- Import registration function from relationships domain
|
|
38
|
+
- Call registration in proper sequence with other domains
|
|
39
|
+
- Export relationship tools for external use
|
|
40
|
+
- Follow existing pattern from other domain registrations
|
|
41
|
+
|
|
42
|
+
## Implementation Notes
|
|
43
|
+
From architecture.md integration points:
|
|
44
|
+
|
|
45
|
+
```typescript
|
|
46
|
+
import { registerRelationshipTools } from './relationships';
|
|
47
|
+
|
|
48
|
+
export function initializeTools(client: QuickbaseClient, cacheService: CacheService): void {
|
|
49
|
+
// ... existing registrations ...
|
|
50
|
+
|
|
51
|
+
// Register relationship management tools
|
|
52
|
+
registerRelationshipTools(client);
|
|
53
|
+
|
|
54
|
+
// ...
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
export * from './relationships';
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
Study existing registrations for:
|
|
61
|
+
- Import statement placement
|
|
62
|
+
- Registration function call order
|
|
63
|
+
- Export pattern for domain tools
|
|
64
|
+
|
|
65
|
+
## Dependencies
|
|
66
|
+
- RELS.1001 - Domain setup complete
|
|
67
|
+
- RELS.1002 - GetRelationshipsTool implemented
|
|
68
|
+
- Existing: src/tools/index.ts, initializeTools function
|
|
69
|
+
|
|
70
|
+
## Risk Assessment
|
|
71
|
+
- **Risk**: Registration breaks existing tool initialization
|
|
72
|
+
- **Mitigation**: Add registration after existing ones; run full test suite
|
|
73
|
+
- **Risk**: Circular dependency issues
|
|
74
|
+
- **Mitigation**: Follow same import pattern as other domains
|
|
75
|
+
|
|
76
|
+
## Files/Packages Affected
|
|
77
|
+
- src/tools/index.ts (update imports, registration, exports)
|
|
78
|
+
- src/__tests__/tools/relationships.test.ts (add integration test)
|
|
79
|
+
|
|
80
|
+
## Deliverables Produced
|
|
81
|
+
|
|
82
|
+
Documents created in `deliverables/` directory:
|
|
83
|
+
|
|
84
|
+
- None
|
|
85
|
+
|
|
86
|
+
## Verification Notes
|
|
87
|
+
Verify-task agent should confirm:
|
|
88
|
+
- Tools registration doesn't break existing tests
|
|
89
|
+
- Full test suite passes (`npm test`)
|
|
90
|
+
- Build completes without errors (`npm run build`)
|
|
91
|
+
- Linting passes (`npm run lint`)
|
|
92
|
+
- Integration test confirms get_relationships appears in toolRegistry.getAllTools()
|
|
93
|
+
- Tool can be retrieved via toolRegistry.getTool('get_relationships')
|
|
94
|
+
- No TypeScript compilation errors
|
|
95
|
+
|
|
96
|
+
Integration test pattern from quality-strategy.md:
|
|
97
|
+
- Tool appears in toolRegistry.getAllTools()
|
|
98
|
+
- Tool can be retrieved by name via toolRegistry.getTool()
|
|
99
|
+
- Execute returns proper ApiResponse structure
|
|
100
|
+
|
|
101
|
+
## Verification Audit
|
|
102
|
+
<!-- Audit log maintained by verify-task agent for enterprise compliance -->
|
|
103
|
+
| Date | Agent | Decision | Notes |
|
|
104
|
+
|------|-------|----------|-------|
|
|
105
|
+
| 2025-12-28 | verify-task | PASS | All 6 acceptance criteria met, 100 tests passing, build successful |
|
|
@@ -0,0 +1,151 @@
|
|
|
1
|
+
# Task: [RELS.2001]: Implement CreateRelationshipTool
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
- [x] **Task completed** - acceptance criteria met
|
|
5
|
+
- [x] **Tests pass** - tests executed and passing (or N/A if no tests)
|
|
6
|
+
- [x] **Verified** - by the verify-task agent
|
|
7
|
+
|
|
8
|
+
**Note on "Tests pass"**:
|
|
9
|
+
- If tests were created/modified, you MUST run them and show output
|
|
10
|
+
- "Tests pass" means tests were EXECUTED and all passed
|
|
11
|
+
- "Tests pass - N/A" is only valid for documentation-only tickets
|
|
12
|
+
- Test file existence alone does NOT satisfy this requirement
|
|
13
|
+
|
|
14
|
+
## Agents
|
|
15
|
+
- implement-feature
|
|
16
|
+
- unit-test-runner
|
|
17
|
+
- verify-task
|
|
18
|
+
- commit-task
|
|
19
|
+
|
|
20
|
+
## Summary
|
|
21
|
+
Implement the `create_relationship` tool to create new table-to-table relationships with optional lookup and summary fields.
|
|
22
|
+
|
|
23
|
+
## Background
|
|
24
|
+
This is the first write operation for relationships. It allows creating new relationships between tables, optionally including lookup fields (to display parent data in child records) and summary fields (to aggregate child data in parent records). The tool must emphasize this is a SAFE operation that doesn't modify existing data.
|
|
25
|
+
|
|
26
|
+
This implements Phase 2 from plan.md: Write Operations - Create and Update.
|
|
27
|
+
|
|
28
|
+
## Acceptance Criteria
|
|
29
|
+
- [x] Tool name is `create_relationship` (snake_case)
|
|
30
|
+
- [x] Tool extends BaseTool with proper TypeScript types
|
|
31
|
+
- [x] Creates basic relationships (parent + child table only)
|
|
32
|
+
- [x] Supports optional lookup_field_ids parameter
|
|
33
|
+
- [x] Supports optional summary field parameters
|
|
34
|
+
- [x] JSON Schema conditional validation: summary_accumulation_type required when summary_field_id provided
|
|
35
|
+
- [x] Tool description emphasizes this is a SAFE operation
|
|
36
|
+
- [x] Tool registered in relationships/index.ts
|
|
37
|
+
- [x] Unit tests cover all parameter combinations and validation scenarios
|
|
38
|
+
- [x] All tests pass with `npm test`
|
|
39
|
+
|
|
40
|
+
## Technical Requirements
|
|
41
|
+
- Endpoint: POST `/tables/{tableId}/relationships`
|
|
42
|
+
- Parameters follow flat structure from architecture.md
|
|
43
|
+
- Support all summary accumulation types: SUM, COUNT, AVG, MAX, MIN
|
|
44
|
+
- Support optional summary_where filter
|
|
45
|
+
- Build request body from flat parameters
|
|
46
|
+
- Return complete relationship structure including created fields
|
|
47
|
+
- Conditional validation: summary_accumulation_type is required if summary_field_id is provided
|
|
48
|
+
|
|
49
|
+
## Implementation Notes
|
|
50
|
+
From architecture.md:
|
|
51
|
+
|
|
52
|
+
```typescript
|
|
53
|
+
interface CreateRelationshipParams {
|
|
54
|
+
table_id: string; // Required: Child table ID
|
|
55
|
+
parent_table_id: string; // Required: Parent table ID
|
|
56
|
+
foreign_key_label?: string; // Optional: Label for reference field
|
|
57
|
+
lookup_field_ids?: number[]; // Optional: Parent field IDs to create as lookups
|
|
58
|
+
summary_field_id?: number; // Optional: Child field ID to summarize
|
|
59
|
+
summary_label?: string; // Optional: Label for summary field
|
|
60
|
+
summary_accumulation_type?: string; // Required if summary_field_id: SUM/COUNT/AVG/MAX/MIN
|
|
61
|
+
summary_where?: string; // Optional: Quickbase query filter for summary
|
|
62
|
+
}
|
|
63
|
+
|
|
64
|
+
interface CreateRelationshipResult {
|
|
65
|
+
id: number;
|
|
66
|
+
parentTableId: string;
|
|
67
|
+
childTableId: string;
|
|
68
|
+
foreignKeyField: FieldInfo;
|
|
69
|
+
lookupFields: FieldInfo[];
|
|
70
|
+
summaryFields: FieldInfo[];
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
JSON Schema must use conditional validation:
|
|
75
|
+
```typescript
|
|
76
|
+
paramSchema = {
|
|
77
|
+
type: 'object',
|
|
78
|
+
properties: { /* ... */ },
|
|
79
|
+
required: ['table_id', 'parent_table_id'],
|
|
80
|
+
// Add conditional validation
|
|
81
|
+
if: {
|
|
82
|
+
properties: { summary_field_id: { type: 'number' } },
|
|
83
|
+
required: ['summary_field_id']
|
|
84
|
+
},
|
|
85
|
+
then: {
|
|
86
|
+
required: ['summary_accumulation_type']
|
|
87
|
+
}
|
|
88
|
+
};
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Tool description (from architecture.md):
|
|
92
|
+
```
|
|
93
|
+
Creates a new table-to-table relationship linking a child table to a parent table.
|
|
94
|
+
This creates a reference field in the child table. Optionally creates lookup fields
|
|
95
|
+
(to display parent data in child records) and/or a summary field (to aggregate child
|
|
96
|
+
data in parent records). Relationships can only be created between tables in the same
|
|
97
|
+
application. This operation is SAFE and does not modify existing data.
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
## Dependencies
|
|
101
|
+
- RELS.1001 - Domain setup complete
|
|
102
|
+
- RELS.1002 - GetRelationshipsTool provides validation pattern
|
|
103
|
+
- RELS.1003 - Registration infrastructure ready
|
|
104
|
+
|
|
105
|
+
## Risk Assessment
|
|
106
|
+
- **Risk**: Validation complexity for conditional summary parameters
|
|
107
|
+
- **Mitigation**: Use JSON Schema conditional validation; clear error messages
|
|
108
|
+
- **Risk**: Creating relationship that already exists
|
|
109
|
+
- **Mitigation**: Handle API error gracefully; include helpful error message
|
|
110
|
+
- **Risk**: Tables in different applications
|
|
111
|
+
- **Mitigation**: API will reject; surface error message clearly
|
|
112
|
+
|
|
113
|
+
## Files/Packages Affected
|
|
114
|
+
- src/tools/relationships/create_relationship.ts (new file)
|
|
115
|
+
- src/tools/relationships/index.ts (update exports and registration)
|
|
116
|
+
- src/__tests__/tools/relationships.test.ts (extend tests)
|
|
117
|
+
|
|
118
|
+
## Deliverables Produced
|
|
119
|
+
|
|
120
|
+
Documents created in `deliverables/` directory:
|
|
121
|
+
|
|
122
|
+
- None
|
|
123
|
+
|
|
124
|
+
## Verification Notes
|
|
125
|
+
Verify-task agent should confirm tests cover all critical paths from quality-strategy.md:
|
|
126
|
+
|
|
127
|
+
Happy Path:
|
|
128
|
+
- Basic relationship creation (parent + child only)
|
|
129
|
+
- With lookup field IDs
|
|
130
|
+
- With summary field (all accumulation types: SUM, COUNT, AVG, MAX, MIN)
|
|
131
|
+
- With both lookup and summary fields
|
|
132
|
+
|
|
133
|
+
Error Cases:
|
|
134
|
+
- Parent table not found
|
|
135
|
+
- Invalid field IDs for lookups
|
|
136
|
+
- Missing accumulation type when summary_field_id provided (validated by JSON Schema)
|
|
137
|
+
- Tables in different apps
|
|
138
|
+
|
|
139
|
+
Edge Cases:
|
|
140
|
+
- Creating relationship that already exists
|
|
141
|
+
- Summary field with WHERE filter
|
|
142
|
+
|
|
143
|
+
Verify conditional validation works:
|
|
144
|
+
- Providing summary_field_id without summary_accumulation_type MUST fail validation
|
|
145
|
+
- Error message clearly explains missing accumulation_type
|
|
146
|
+
|
|
147
|
+
## Verification Audit
|
|
148
|
+
<!-- Audit log maintained by verify-task agent for enterprise compliance -->
|
|
149
|
+
| Date | Agent | Decision | Notes |
|
|
150
|
+
|------|-------|----------|-------|
|
|
151
|
+
| 2025-12-28 | verify-task | PASS | All 10 acceptance criteria met, 123 tests passing, 100% line/branch/statement coverage on create_relationship.ts |
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
# Task: [RELS.2002]: Implement UpdateRelationshipTool
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
- [x] **Task completed** - acceptance criteria met
|
|
5
|
+
- [x] **Tests pass** - tests executed and passing (or N/A if no tests)
|
|
6
|
+
- [x] **Verified** - by the verify-task agent
|
|
7
|
+
|
|
8
|
+
**Note on "Tests pass"**:
|
|
9
|
+
- If tests were created/modified, you MUST run them and show output
|
|
10
|
+
- "Tests pass" means tests were EXECUTED and all passed
|
|
11
|
+
- "Tests pass - N/A" is only valid for documentation-only tickets
|
|
12
|
+
- Test file existence alone does NOT satisfy this requirement
|
|
13
|
+
|
|
14
|
+
## Agents
|
|
15
|
+
- implement-feature
|
|
16
|
+
- unit-test-runner
|
|
17
|
+
- verify-task
|
|
18
|
+
- commit-task
|
|
19
|
+
|
|
20
|
+
## Summary
|
|
21
|
+
Implement the `update_relationship` tool to add lookup and summary fields to existing relationships. This tool is ADDITIVE ONLY - it will not delete existing fields.
|
|
22
|
+
|
|
23
|
+
## Background
|
|
24
|
+
This tool enhances existing relationships by adding new lookup or summary fields. It's critical that agents understand this is additive only - fields can only be removed by using separate field deletion tools. The tool description must clearly state "ADDITIVE ONLY" to prevent confusion.
|
|
25
|
+
|
|
26
|
+
This completes Phase 2 from plan.md: Write Operations - Create and Update.
|
|
27
|
+
|
|
28
|
+
## Acceptance Criteria
|
|
29
|
+
- [x] Tool name is `update_relationship` (snake_case)
|
|
30
|
+
- [x] Tool extends BaseTool with proper TypeScript types
|
|
31
|
+
- [x] Adds lookup fields to existing relationships
|
|
32
|
+
- [x] Adds summary fields to existing relationships
|
|
33
|
+
- [x] JSON Schema conditional validation: summary_accumulation_type required when summary_field_id provided
|
|
34
|
+
- [x] Tool description clearly states "ADDITIVE ONLY"
|
|
35
|
+
- [x] Tool description explains how to remove fields (use field deletion tools)
|
|
36
|
+
- [x] Tool registered in relationships/index.ts
|
|
37
|
+
- [x] Unit tests cover additive behavior and all error scenarios
|
|
38
|
+
- [x] All tests pass with `npm test`
|
|
39
|
+
|
|
40
|
+
## Technical Requirements
|
|
41
|
+
- Endpoint: POST `/tables/{tableId}/relationships/{relationshipId}`
|
|
42
|
+
- Parameters similar to create_relationship but require relationship_id
|
|
43
|
+
- Support adding lookup_field_ids
|
|
44
|
+
- Support adding summary field with accumulation type
|
|
45
|
+
- Conditional validation: summary_accumulation_type required if summary_field_id provided
|
|
46
|
+
- Return updated relationship structure
|
|
47
|
+
- Does NOT delete existing fields (API behavior, verify in tests)
|
|
48
|
+
|
|
49
|
+
## Implementation Notes
|
|
50
|
+
From architecture.md:
|
|
51
|
+
|
|
52
|
+
```typescript
|
|
53
|
+
interface UpdateRelationshipParams {
|
|
54
|
+
table_id: string; // Required: Child table ID
|
|
55
|
+
relationship_id: number; // Required: Relationship ID (foreign key field ID)
|
|
56
|
+
lookup_field_ids?: number[]; // Optional: Additional parent field IDs for lookups
|
|
57
|
+
summary_field_id?: number; // Optional: Child field ID to summarize
|
|
58
|
+
summary_label?: string; // Optional: Label for summary field
|
|
59
|
+
summary_accumulation_type?: string; // Required if summary_field_id
|
|
60
|
+
summary_where?: string; // Optional: Quickbase query filter
|
|
61
|
+
}
|
|
62
|
+
|
|
63
|
+
interface UpdateRelationshipResult {
|
|
64
|
+
id: number;
|
|
65
|
+
parentTableId: string;
|
|
66
|
+
childTableId: string;
|
|
67
|
+
foreignKeyField: FieldInfo;
|
|
68
|
+
lookupFields: FieldInfo[];
|
|
69
|
+
summaryFields: FieldInfo[];
|
|
70
|
+
}
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
JSON Schema must use same conditional validation as create_relationship:
|
|
74
|
+
```typescript
|
|
75
|
+
if: {
|
|
76
|
+
properties: { summary_field_id: { type: 'number' } },
|
|
77
|
+
required: ['summary_field_id']
|
|
78
|
+
},
|
|
79
|
+
then: {
|
|
80
|
+
required: ['summary_accumulation_type']
|
|
81
|
+
}
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Tool description (from architecture.md):
|
|
85
|
+
```
|
|
86
|
+
Adds lookup fields and/or summary fields to an existing relationship. This operation
|
|
87
|
+
is ADDITIVE ONLY - it will not delete existing lookup or summary fields. Use this to
|
|
88
|
+
enhance relationships with additional calculated fields. To remove fields from a
|
|
89
|
+
relationship, you must delete them individually using the field deletion tools.
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## Dependencies
|
|
93
|
+
- RELS.1001 - Domain setup complete
|
|
94
|
+
- RELS.2001 - CreateRelationshipTool provides pattern for summary validation
|
|
95
|
+
- Existing: Field deletion tools (mentioned in description)
|
|
96
|
+
|
|
97
|
+
## Risk Assessment
|
|
98
|
+
- **Risk**: Agents expect update to replace fields instead of adding
|
|
99
|
+
- **Mitigation**: Clear "ADDITIVE ONLY" in description; test and document behavior
|
|
100
|
+
- **Risk**: Adding fields that already exist
|
|
101
|
+
- **Mitigation**: Handle API response appropriately; test edge case
|
|
102
|
+
- **Risk**: Empty update (no fields to add)
|
|
103
|
+
- **Mitigation**: Allow but may be no-op; test and document behavior
|
|
104
|
+
|
|
105
|
+
## Files/Packages Affected
|
|
106
|
+
- src/tools/relationships/update_relationship.ts (new file)
|
|
107
|
+
- src/tools/relationships/index.ts (update exports and registration)
|
|
108
|
+
- src/__tests__/tools/relationships.test.ts (extend tests)
|
|
109
|
+
|
|
110
|
+
## Deliverables Produced
|
|
111
|
+
|
|
112
|
+
Documents created in `deliverables/` directory:
|
|
113
|
+
|
|
114
|
+
- None
|
|
115
|
+
|
|
116
|
+
## Verification Notes
|
|
117
|
+
Verify-task agent should confirm tests cover all critical paths from quality-strategy.md:
|
|
118
|
+
|
|
119
|
+
Happy Path:
|
|
120
|
+
- Add lookup fields to existing relationship
|
|
121
|
+
- Add summary field to existing relationship
|
|
122
|
+
- Add both lookup and summary fields
|
|
123
|
+
|
|
124
|
+
Error Cases:
|
|
125
|
+
- Relationship not found
|
|
126
|
+
- Invalid lookup field IDs
|
|
127
|
+
- Missing accumulation type when summary_field_id provided (validated by JSON Schema)
|
|
128
|
+
|
|
129
|
+
Edge Cases:
|
|
130
|
+
- Adding fields that already exist (verify additive behavior)
|
|
131
|
+
- Empty update (no fields to add)
|
|
132
|
+
|
|
133
|
+
Verify conditional validation works:
|
|
134
|
+
- Providing summary_field_id without summary_accumulation_type MUST fail validation
|
|
135
|
+
|
|
136
|
+
Verify additive behavior:
|
|
137
|
+
- Adding new lookup fields doesn't remove existing ones
|
|
138
|
+
- Adding summary field doesn't affect existing lookups
|
|
139
|
+
- Result includes ALL fields (existing + newly added)
|
|
140
|
+
|
|
141
|
+
## Verification Audit
|
|
142
|
+
<!-- Audit log maintained by verify-task agent for enterprise compliance -->
|
|
143
|
+
| Date | Agent | Decision | Notes |
|
|
144
|
+
|------|-------|----------|-------|
|
|
145
|
+
| 2025-12-28 | verify-task | PASS | All 10 acceptance criteria met, 143 tests passing, 100% coverage on relationships tools |
|