@codyswann/lisa 2.166.3 → 2.166.5
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/package.json +5 -5
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/skills/harper-config-yaml/SKILL.md +172 -1
- package/plugins/lisa-harper-fabric/skills/harper-schema-graphql/SKILL.md +68 -17
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/skills/harper-config-yaml/SKILL.md +172 -1
- package/plugins/lisa-harper-fabric-agy/skills/harper-schema-graphql/SKILL.md +68 -17
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/skills/harper-config-yaml/SKILL.md +172 -1
- package/plugins/lisa-harper-fabric-copilot/skills/harper-schema-graphql/SKILL.md +68 -17
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/skills/harper-config-yaml/SKILL.md +172 -1
- package/plugins/lisa-harper-fabric-cursor/skills/harper-schema-graphql/SKILL.md +68 -17
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/harper-fabric/skills/harper-config-yaml/SKILL.md +172 -1
- package/plugins/src/harper-fabric/skills/harper-schema-graphql/SKILL.md +68 -17
package/package.json
CHANGED
|
@@ -85,7 +85,7 @@
|
|
|
85
85
|
"lodash": ">=4.18.1"
|
|
86
86
|
},
|
|
87
87
|
"name": "@codyswann/lisa",
|
|
88
|
-
"version": "2.166.
|
|
88
|
+
"version": "2.166.5",
|
|
89
89
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
90
90
|
"main": "dist/index.js",
|
|
91
91
|
"exports": {
|
|
@@ -166,7 +166,7 @@
|
|
|
166
166
|
"@types/jest": "^30.0.0",
|
|
167
167
|
"@types/lodash.merge": "^4.6.0",
|
|
168
168
|
"@types/node": "^22.0.0",
|
|
169
|
-
"@vitest/coverage-v8": "^4.1.
|
|
169
|
+
"@vitest/coverage-v8": "^4.1.9",
|
|
170
170
|
"commander": "^12.0.0",
|
|
171
171
|
"esbuild-register": "^3.6.0",
|
|
172
172
|
"eslint": "^9.39.0",
|
|
@@ -205,17 +205,17 @@
|
|
|
205
205
|
"tsx": "^4.0.0",
|
|
206
206
|
"typescript": "^6.0.3",
|
|
207
207
|
"typescript-eslint": "^8.0.0",
|
|
208
|
-
"vitest": "^4.1.
|
|
208
|
+
"vitest": "^4.1.9"
|
|
209
209
|
},
|
|
210
210
|
"devDependencies": {
|
|
211
|
-
"@codyswann/lisa": "^2.
|
|
211
|
+
"@codyswann/lisa": "^2.166.4",
|
|
212
212
|
"@types/js-yaml": "^4.0.9",
|
|
213
213
|
"@types/semver": "^7.7.1",
|
|
214
214
|
"eslint-plugin-oxlint": "^1.62.0",
|
|
215
215
|
"js-yaml": "^4.1.1",
|
|
216
216
|
"oxlint": "^1.62.0",
|
|
217
217
|
"oxlint-tsgolint": "^0.22.1",
|
|
218
|
-
"vite": "^8.0.
|
|
218
|
+
"vite": "^8.0.16"
|
|
219
219
|
},
|
|
220
220
|
"type": "module"
|
|
221
221
|
}
|
|
@@ -66,6 +66,175 @@ For real-time work, component `config.yaml` keeps `rest`, `graphqlSchema`, and
|
|
|
66
66
|
MQTT topic paths. Broker ports and MQTT authentication live in the root
|
|
67
67
|
`harper-config.yaml`, not the component file. See [[harper-realtime]].
|
|
68
68
|
|
|
69
|
+
## `dataLoader`: seed data
|
|
70
|
+
|
|
71
|
+
Use `dataLoader` for versioned seed/reference records that should exist whenever
|
|
72
|
+
the component is deployed. Define table shape first with `graphqlSchema`, then
|
|
73
|
+
point `dataLoader.files` at one or more JSON/YAML files:
|
|
74
|
+
|
|
75
|
+
```yaml
|
|
76
|
+
graphqlSchema:
|
|
77
|
+
files: 'schema.graphql'
|
|
78
|
+
dataLoader:
|
|
79
|
+
files:
|
|
80
|
+
- 'data/roles.yaml'
|
|
81
|
+
- 'data/reference/*.json'
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Each data file targets exactly one table and has `database`, `table`, and
|
|
85
|
+
`records` keys:
|
|
86
|
+
|
|
87
|
+
```yaml
|
|
88
|
+
database: app
|
|
89
|
+
table: Role
|
|
90
|
+
records:
|
|
91
|
+
- id: admin
|
|
92
|
+
name: Administrator
|
|
93
|
+
permissions:
|
|
94
|
+
- users:read
|
|
95
|
+
- users:write
|
|
96
|
+
- id: viewer
|
|
97
|
+
name: Viewer
|
|
98
|
+
permissions:
|
|
99
|
+
- users:read
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
Harper runs the loader on full system starts and component deployments. It is
|
|
103
|
+
safe to re-run when files are idempotent: new records are inserted, unchanged
|
|
104
|
+
records are skipped, and records are updated from the file only when the tracked
|
|
105
|
+
file content changed. User-created records and user edits made after an initial
|
|
106
|
+
load are preserved; changed data-loaded records are patched instead of blindly
|
|
107
|
+
replaced.
|
|
108
|
+
|
|
109
|
+
Choose `dataLoader` for small, source-controlled reference/configuration data
|
|
110
|
+
that should ship with the component. Use a REST/Operations API script or job for
|
|
111
|
+
large imports, environment-specific backfills, or one-off migrations where retry
|
|
112
|
+
scope and operator approval matter.
|
|
113
|
+
|
|
114
|
+
Verify locally:
|
|
115
|
+
|
|
116
|
+
```bash
|
|
117
|
+
harper dev harper-app
|
|
118
|
+
curl -s http://localhost:9926/app/Role/admin
|
|
119
|
+
harper dev harper-app # restart/redeploy and confirm the seed did not duplicate
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## `fastifyRoutes`: custom HTTP routes
|
|
123
|
+
|
|
124
|
+
Prefer `jsResource` plus `rest` for normal CRUD/action APIs. Use `fastifyRoutes`
|
|
125
|
+
only when the route shape does not fit the Resource model: webhooks, custom
|
|
126
|
+
serialization, unusual path matching, or a compatibility endpoint.
|
|
127
|
+
|
|
128
|
+
```yaml
|
|
129
|
+
rest: true
|
|
130
|
+
graphqlSchema:
|
|
131
|
+
files: 'schema.graphql'
|
|
132
|
+
jsResource:
|
|
133
|
+
files: 'resources.js'
|
|
134
|
+
fastifyRoutes:
|
|
135
|
+
files: 'routes/*.js'
|
|
136
|
+
urlPath: 'hooks'
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
Route modules default-export an async function that receives the Fastify server
|
|
140
|
+
and Harper helpers:
|
|
141
|
+
|
|
142
|
+
```js
|
|
143
|
+
export default async (server, { hdbCore, logger }) => {
|
|
144
|
+
server.route({
|
|
145
|
+
method: 'POST',
|
|
146
|
+
url: '/payment/:provider',
|
|
147
|
+
preValidation: hdbCore.preValidation,
|
|
148
|
+
handler: async (request, reply) => {
|
|
149
|
+
logger.debug(`payment webhook ${request.params.provider}`);
|
|
150
|
+
request.body = {
|
|
151
|
+
operation: 'insert',
|
|
152
|
+
schema: 'app',
|
|
153
|
+
table: 'WebhookEvent',
|
|
154
|
+
records: [
|
|
155
|
+
{
|
|
156
|
+
id: request.headers['x-event-id'],
|
|
157
|
+
provider: request.params.provider,
|
|
158
|
+
payload: request.body,
|
|
159
|
+
},
|
|
160
|
+
],
|
|
161
|
+
};
|
|
162
|
+
const result = await hdbCore.request(request);
|
|
163
|
+
return { ok: true, result };
|
|
164
|
+
},
|
|
165
|
+
});
|
|
166
|
+
};
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
Use Fastify's `request.params`, `request.query`, `request.body`, and `request.headers`
|
|
170
|
+
for route inputs. Keep auth explicit: `hdbCore.request` should be paired with
|
|
171
|
+
`hdbCore.preValidation` so Harper authenticates the request. Avoid
|
|
172
|
+
`requestWithoutAuthentication` unless the route has its own signature/JWT check
|
|
173
|
+
and all user-provided values are bound or escaped; never build SQL strings by
|
|
174
|
+
interpolating params/body values.
|
|
175
|
+
|
|
176
|
+
Verify locally:
|
|
177
|
+
|
|
178
|
+
```bash
|
|
179
|
+
harper dev harper-app
|
|
180
|
+
curl -i -X POST http://localhost:9926/app/hooks/payment/stripe \
|
|
181
|
+
-H 'Authorization: Basic ...' \
|
|
182
|
+
-H 'Content-Type: application/json' \
|
|
183
|
+
-H 'x-event-id: evt_123' \
|
|
184
|
+
--data '{"status":"paid"}'
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
## `static`: serve web assets and SPAs
|
|
188
|
+
|
|
189
|
+
Use `static` to serve generated browser output or other immutable assets from
|
|
190
|
+
the component. In Lisa Harper Fabric projects, `harper-app/web/**` is generated
|
|
191
|
+
by the project build; edit the source UI under `src/`, not the deployed files.
|
|
192
|
+
|
|
193
|
+
```yaml
|
|
194
|
+
static:
|
|
195
|
+
files: 'web/**'
|
|
196
|
+
urlPath: '.'
|
|
197
|
+
index: true
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
`files` selects what is served. `urlPath` mounts those files under a URL prefix:
|
|
201
|
+
`urlPath: 'app'` makes `web/index.html` available at `/app/index.html`; the
|
|
202
|
+
default application path still includes the Harper project/component prefix. Use
|
|
203
|
+
`index: true` to serve `index.html` for directory requests, and `extensions:
|
|
204
|
+
['html']` when clean URLs should resolve to `.html` files.
|
|
205
|
+
|
|
206
|
+
For client-side-routed SPAs, return the app shell for unmatched asset paths:
|
|
207
|
+
|
|
208
|
+
```yaml
|
|
209
|
+
static:
|
|
210
|
+
files: 'web/**'
|
|
211
|
+
urlPath: '.'
|
|
212
|
+
index: true
|
|
213
|
+
fallthrough: false
|
|
214
|
+
notFound:
|
|
215
|
+
file: 'web/index.html'
|
|
216
|
+
statusCode: 200
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
That fallback is for browser routes such as `/reports/weekly`; it should not hide
|
|
220
|
+
missing API endpoints or broken asset names. Keep API routes under a clear
|
|
221
|
+
prefix, and check that hashed JS/CSS assets still return their actual files.
|
|
222
|
+
|
|
223
|
+
Harper's documented `static` config controls path matching and not-found
|
|
224
|
+
behavior, not custom cache policy. Treat MIME type and cache headers as runtime
|
|
225
|
+
behavior to verify with `curl -I`; if the app needs precise cache headers,
|
|
226
|
+
front it with an edge/proxy policy or a custom route designed for that asset
|
|
227
|
+
surface.
|
|
228
|
+
|
|
229
|
+
Verify locally:
|
|
230
|
+
|
|
231
|
+
```bash
|
|
232
|
+
harper dev harper-app
|
|
233
|
+
curl -I http://localhost:9926/app/
|
|
234
|
+
curl -I http://localhost:9926/app/assets/index.js
|
|
235
|
+
curl -I http://localhost:9926/app/client-side-route
|
|
236
|
+
```
|
|
237
|
+
|
|
69
238
|
## External components and custom plugins
|
|
70
239
|
|
|
71
240
|
A component you depend on from npm needs a `package:` directive matching a
|
|
@@ -109,4 +278,6 @@ dropped an extension often fails only at runtime, not at build time.
|
|
|
109
278
|
## Sources
|
|
110
279
|
|
|
111
280
|
- [Components overview](https://docs.harperdb.io/reference/v5/components/overview)
|
|
112
|
-
- [
|
|
281
|
+
- [Data Loader](https://docs.harperdb.io/reference/v5/database/data-loader)
|
|
282
|
+
- [Fastify Routes](https://docs.harperdb.io/reference/v5/fastify-routes/overview)
|
|
283
|
+
- [Static Files](https://docs.harperdb.io/reference/v5/static-files/overview)
|
|
@@ -16,28 +16,39 @@ the REST/GraphQL surface exposes.
|
|
|
16
16
|
## Defining tables
|
|
17
17
|
|
|
18
18
|
A table is a GraphQL type. Harper-specific directives mark a type as a persisted
|
|
19
|
-
table and control exposure, primary keys,
|
|
20
|
-
|
|
21
|
-
|
|
19
|
+
table and control exposure, primary keys, indexes, audit timestamps, sealed
|
|
20
|
+
records, and relationships. Lisa's Harper Fabric template pins `harperdb` to the
|
|
21
|
+
Harper 4 line (`^4.7.29`), so use this v4 directive reference for template
|
|
22
|
+
projects:
|
|
22
23
|
|
|
23
24
|
```graphql
|
|
24
|
-
type Dog @table {
|
|
25
|
-
id:
|
|
25
|
+
type Dog @table @export(name: "dogs") {
|
|
26
|
+
id: Long @primaryKey
|
|
26
27
|
name: String @indexed
|
|
27
28
|
breed: String
|
|
28
|
-
|
|
29
|
+
ownerId: Long @indexed
|
|
30
|
+
owner: Owner @relationship(from: ownerId)
|
|
31
|
+
createdAt: Long @createdTime
|
|
32
|
+
updatedAt: Long @updatedTime
|
|
29
33
|
}
|
|
30
34
|
```
|
|
31
35
|
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
36
|
+
| Directive | Scope | Syntax | Use |
|
|
37
|
+
| --- | --- | --- | --- |
|
|
38
|
+
| `@table` | Type | `type Product @table { ... }` | Creates a persisted table named after the type. Optional arguments: `table: "products"` to override the table name, `database: "commerce"` to choose a database, `expiration: 3600` for TTL-style records, and `audit: true` to force audit logging. |
|
|
39
|
+
| `@export` | Type | `type Product @table @export(name: "products") { ... }` | Exposes the table as a resource endpoint for REST/MQTT and related surfaces. `name` is optional; without it the type name is the path segment. |
|
|
40
|
+
| `@sealed` | Type | `type Product @table @sealed { ... }` | Rejects undeclared properties. Omit it when the table intentionally accepts extra record fields. |
|
|
41
|
+
| `@primaryKey` | Field | `id: Long @primaryKey` | Marks the unique table key. If omitted on insert, Harper v4 can auto-generate a UUID for `String`/`ID` keys or an auto-incrementing integer for `Int`/`Long`/`Any` keys. Prefer `Long` or `Any` for generated numeric keys. |
|
|
42
|
+
| `@indexed` | Field | `sku: String @indexed` | Adds a secondary index used by REST filters, SQL, and NoSQL/search paths. Array fields index each element. For vectors in Harper v4.6+, use `embedding: [Float] @indexed(type: "HNSW")`. |
|
|
43
|
+
| `@createdTime` | Field | `createdAt: Long @createdTime` | Writes Unix epoch milliseconds when the record is created. |
|
|
44
|
+
| `@updatedTime` | Field | `updatedAt: Long @updatedTime` | Writes Unix epoch milliseconds whenever the record is updated. |
|
|
45
|
+
| `@relationship(from: field)` | Field | `owner: Owner @relationship(from: ownerId)` | The foreign key is on this table and references the target table primary key. If the foreign key field is an array, the relationship is many-to-many. |
|
|
46
|
+
| `@relationship(to: field)` | Field | `dogs: [Dog] @relationship(to: ownerId)` | The foreign key is on the target table. The relationship field must be an array. |
|
|
47
|
+
| `@relationship(from: field, to: field)` | Field | `product: Product @relationship(from: productSku, to: sku)` | Joins this table's field to a non-primary-key field on the target table. Index both join fields. |
|
|
48
|
+
|
|
49
|
+
Use v5 docs only when the downstream project has intentionally moved off the Lisa
|
|
50
|
+
template's Harper 4 dependency; do not mix v5-only syntax into a `harperdb`
|
|
51
|
+
`^4.7.29` project.
|
|
41
52
|
|
|
42
53
|
## How the schema drives the app
|
|
43
54
|
|
|
@@ -48,6 +59,45 @@ type Dog @table {
|
|
|
48
59
|
or removal in the schema is a breaking change for every resource and verify path
|
|
49
60
|
that references it.
|
|
50
61
|
|
|
62
|
+
## Schema evolution
|
|
63
|
+
|
|
64
|
+
Schema changes are deploy-time data-model changes, not just type edits. Harper's
|
|
65
|
+
`graphqlSchema` extension ensures declared tables and attributes exist when the
|
|
66
|
+
component loads, but it does not perform semantic data migrations such as
|
|
67
|
+
renaming tables, copying field values, or rewriting existing rows for you.
|
|
68
|
+
|
|
69
|
+
Classify each change before editing:
|
|
70
|
+
|
|
71
|
+
| Change | Compatibility | What Harper does | Required agent work |
|
|
72
|
+
| --- | --- | --- | --- |
|
|
73
|
+
| Add optional field | Usually safe | Adds the declared attribute shape; existing rows read as missing/`null` until written. | Update resources, seeds, and verification that should include the field. |
|
|
74
|
+
| Add required/non-null field | Breaking for existing rows and writers | The schema can declare the field, but existing records do not magically gain valid values. | Backfill first or deploy as optional, populate, then tighten in a later deploy. |
|
|
75
|
+
| Add `@indexed` | Usually safe, operationally sensitive | Creates/uses a secondary index for the attribute. Large tables may pay rebuild cost. | Verify filtered REST/search paths and note index build risk in the deploy runbook. |
|
|
76
|
+
| Add `@sealed` | Breaking when rows or writers use extra properties | Future writes with undeclared properties are rejected. | Audit current data/writers, declare needed fields, or migrate callers before sealing. |
|
|
77
|
+
| Rename field | Breaking | Treated as a new field; the old field and its values are not transformed. | Add the new field, copy values with a migration, update code, verify, then remove old usage. |
|
|
78
|
+
| Rename type/table | Breaking | Harper v4 does not rename tables; changing the type name creates a new empty table and leaves the old table/data untouched. | Create the new table, copy data, update resources/routes, verify both read/write paths, then retire the old table intentionally. |
|
|
79
|
+
| Change field type | Breaking | Existing stored values are not coerced into the new type in a controlled migration. | Add a replacement field/table, transform data with code, verify, then remove old usage. |
|
|
80
|
+
| Remove field/type | Breaking | Schema no longer declares it, but dependent resources, routes, queries, seeds, and clients can still reference it. | Delete references first, run a migration/cleanup if needed, and verify old API paths fail or redirect intentionally. |
|
|
81
|
+
|
|
82
|
+
Migration recipe for production data:
|
|
83
|
+
|
|
84
|
+
1. Add the new schema shape in a backward-compatible way: new table or nullable
|
|
85
|
+
replacement field, keeping the old field/table available.
|
|
86
|
+
2. Write a one-shot migration using a Harper resource method or Operations
|
|
87
|
+
API/script that reads old rows, transforms values, and writes the new shape.
|
|
88
|
+
Make it idempotent; reruns should skip rows already migrated or compare a
|
|
89
|
+
migration marker.
|
|
90
|
+
3. Deploy to one Fabric environment and run the migration before switching
|
|
91
|
+
readers/writers. For replicated Fabric deployments, assume every node may see
|
|
92
|
+
the new code/schema at slightly different times; keep old and new reads
|
|
93
|
+
compatible until replication and smoke checks are green.
|
|
94
|
+
4. Update resources, REST/GraphQL queries, data-loader seeds, and verify scripts
|
|
95
|
+
in the same PR. A schema PR is incomplete if `bun run verify` or the project
|
|
96
|
+
smoke path cannot prove the migrated read/write behavior.
|
|
97
|
+
5. Roll back by reverting code/schema only when the old field/table remains
|
|
98
|
+
intact. Once cleanup drops old data or callers, rollback needs a reverse
|
|
99
|
+
migration and a restored compatibility path.
|
|
100
|
+
|
|
51
101
|
## Project conventions
|
|
52
102
|
|
|
53
103
|
- `schema.graphql` is **source** and lives at the component root that Fabric
|
|
@@ -68,5 +118,6 @@ Run any verify path that asserts row counts or joins against the changed model.
|
|
|
68
118
|
|
|
69
119
|
## Sources
|
|
70
120
|
|
|
71
|
-
- [
|
|
72
|
-
- [
|
|
121
|
+
- [Harper v4 Schema](https://docs.harperdb.io/reference/v4/database/schema)
|
|
122
|
+
- [Components overview](https://docs.harperdb.io/reference/v4/components/overview)
|
|
123
|
+
- [Operations API](https://docs.harperdb.io/reference/v4/operations-api/operations)
|