87 lines
7.4 KiB
Markdown
87 lines
7.4 KiB
Markdown
# Foundry service integration evidence
|
|
|
|
Status: step 5 service scope audit completed; overall progress is 5/7.
|
|
This does not complete migration/delivery,
|
|
the complete Draft acceptance matrix, main integration or production deployment.
|
|
|
|
## Verified revisions and environment
|
|
|
|
- Endoleap consumer: `580a14f508bc695bfed99d60c42f0d4df36b15b2`.
|
|
- Foundry: `d00388504cda5ce267b61cc5deb919c71a9d5e25`.
|
|
- [Foundry CI #1178](https://gitea.entroia.com/Zayden-Jung/foundry-core/actions/runs/1178):
|
|
completed successfully; job 1275, all seven steps successful. The previous
|
|
client/service baseline also passed CI #1174 and #1175.
|
|
- Existing `ces-control` runner executes Go checks/build, schema migration and
|
|
isolated PostgreSQL integration, then the pinned Node 24 consumer and HTTP smoke
|
|
checks. No local backend build or Docker execution was used.
|
|
- Local frontend: 785 Node tests and full TypeScript checking passed. Tests use
|
|
the source modules; packaged SDK and application delivery remain separate gates.
|
|
|
|
## What the checks actually prove
|
|
|
|
| Requirement | Authoritative entry and observed assertion |
|
|
| --- | --- |
|
|
| Explicit identity migration | `TestCanonicalModelMigrationAndIncrementalLifecycle`: GET does not migrate; retry returns the same identity map; implicit partitions become owning canvases; old snapshot writers are rejected. The real Node consumer also migrates and retries. |
|
|
| Migration admission and late rollback | `TestCanonicalMigrationPermissionVersionAndRunGuards` checks viewer denial, stale source versions, queued/running work and stable negative receipts after conditions change. `TestCanonicalMigrationLateCancellationRollsBack` observes the actual identity-map INSERT blocked after canonical/material/subgraph writes, cancels it, then checks all related rows, original legacy JSON and version before retrying the original key successfully. |
|
|
| Incremental writes and receipt identity | `TestCanonicalModelMigrationAndIncrementalLifecycle` verifies exact retries, unknown receipt semantics, logical ID coverage, participant versions, and zero writes/logical-ID consumption after a later batch condition fails. It checks canonical DB rows, not just HTTP status. |
|
|
| Canonical concurrent writers | `TestCanonicalConcurrentMigrationAndOwnershipWrites` races four identical migrations, then four identical edits, requiring identical receipts and one version advance. Two different requests then compete to move alternate endpoints and their common edge: exactly one wins, the loser has a queryable terminal version-conflict receipt, both canvas versions advance once, and the full ownership graph remains valid. Reusing the winning key with changed bytes is rejected without changing the model. |
|
|
| Real frontend coordination | `TestHeadlessClientHTTPIntegration` runs `tests/headless/foundry.integration.mjs` against authenticated HTTP and PostgreSQL. It verifies lost document ACK recovery without duplicate POST, atomic partition edits, deep copy with a parent-owned incoming edge, partial import and old stream-tail coordination. |
|
|
| Resources and authorization | The consumer verifies lost upload ACK, shared pending-image upload, original bytes, metadata, cross-project adoption and reopen. `TestOnboardingAndSharing` additionally revokes source access after warm reads, verifies no target model/version/binding changes, preserves the rejected receipt after permission restoration, and checks independent target access. |
|
|
| AI execution identity and controls | `TestCanonicalAIAdmissionAndLifecycle` covers admission/query/retry, zero-effect rejection, old incarnation callbacks, cancellation, managed image output, owner relocation, archived admission routes and execution after permission revocation. |
|
|
| Actual frontend RunPort | `tests/headless/foundry-ai.integration.mjs` exercises `createFoundryRuns`, the HTTP transport and ProjectEngine: successful admission response loss/reopen/query, queued cancellation response loss, generation-time content conflict, explicit apply response loss plus undo/reopen/redo, generated image metadata/original bytes/preview, and copy without a new run or upload. |
|
|
|
|
The CI #1174 consumer report contains `status: "ok"`, 72 HTTP transport calls,
|
|
all 14 prior document/resource flags true, plus `runtimeAI`, `aiLostAdmission`,
|
|
`aiCancelReconciled`, `aiConflictApplyUndo`, `aiManagedImage`, `aiCopyNoRun` true.
|
|
`aiExecutionCount` is exactly 3: text, retained conflict output, image. The queued
|
|
cancelled run never calls generation. Preview fetching is a separate authenticated
|
|
host fetch and is not included in the 72 transport calls.
|
|
CI #1178 repeated the same pinned consumer successfully with 71 transport calls
|
|
and the same flags/execution count. Timing-dependent poll counts are observations,
|
|
not an exact total-call contract; admission/action/upload duplication has separate
|
|
explicit assertions.
|
|
|
|
## Issues exposed by the real consumer
|
|
|
|
1. The standalone AI client omitted the v2 Accept header. The Next proxy had
|
|
supplied it, hiding the omission in application-only testing. `canvas-v2`
|
|
negotiation now belongs to the AI adapter and shared transport; regression
|
|
tests cover all three writes and receipt queries with original body/key/version.
|
|
2. Asset display URLs assumed the application's relative preview route. The
|
|
asset adapter now accepts a host `displayURL(id)` callback. Canonical source
|
|
identity and authority remain separate; preview bytes are not used as original
|
|
file digest evidence. Authentication stays in the host fetch/transport.
|
|
|
|
The test harness also needed working controlled timers, a cancelled run's final
|
|
event drain before the next admission, and actual copy-source file persistence.
|
|
The adoption stage still asserts zero project-local file writes. The subsequent
|
|
copy stage permits source checkpoints but rejects bitmap file duplication and
|
|
asserts no extra upload or generation. Those fixes do not bypass busy, cursor,
|
|
durability or resource-sharing checks.
|
|
|
|
## Boundaries and remaining audit
|
|
|
|
The recovery store is an in-memory durable-batch fixture, and response loss is
|
|
injected after successful HTTP responses. Real IndexedDB/Web Locks/browser
|
|
acceptance is recorded separately in `STEP4_ACCEPTANCE.md`; this service run does
|
|
not combine every browser crash window with every server operation.
|
|
|
|
`canvas_headless_worker_integration_test.go` supplies deterministic generation
|
|
output over the actual worker HTTP protocol. Admission, claim, events, canonical
|
|
writes, image storage and action receipts use the real service/DB. Private worker
|
|
controls are registered only in the test assembly. Production's background queue
|
|
loop, external model availability, provider billing and real CLI authentication
|
|
are not proved by that fixture. `TestCanvasAIRealWorker` remains opt-in and skipped.
|
|
|
|
The CI log includes an early skip of `TestHeadlessClientHTTPIntegration` without
|
|
its opt-in environment and a later successful execution in the explicit Node/DB
|
|
phase. Those are different invocations. The latest log has 157 distinct PASS names
|
|
including subtests; that count is not 154 independent end-to-end scenarios.
|
|
|
|
The service audit covers the original stage requirements: target incremental and
|
|
idempotent protocols, frontend/runtime/resource adapters, explicit legacy
|
|
compatibility, identity mapping, source-version/permission/run admission barriers,
|
|
and rollback after writes have begun. Migration/delivery and the final requirement
|
|
matrix remain. A green feature-branch run does not merge or deploy
|
|
either repository. Foundry PR #19 remains open and Draft.
|