fix: resolve all CI build and test errors

[Copilot]

CI was broken on main due to TypeScript build errors, adapter/test mismatches on discovery endpoints, and incorrect client feed routing.

ObjectQL build (TS2345)

SchemaRegistry.registerItem() calls in protocol.ts failed type checking when T inferred as unknown from getItem() return. Applied 'name' as any cast, consistent with existing pattern in engine.ts and metadata-facade.ts.

loadMetaFromDb object registration

registerItem('object', data) stores in the generic metadata map, but getItem('object', name) delegates to getObject() which reads from objectContributors. Objects registered via registerItem were invisible to lookups. Fixed by routing object-type records through registerObject():

if (record.type === 'object') {
    SchemaRegistry.registerObject(data as any, record.packageId || 'sys_metadata');
} else {
    SchemaRegistry.registerItem(record.type, data, 'name' as any);
}

Adapter discovery endpoints (hono, sveltekit, nuxt, nextjs, fastify)

All five adapters served discovery at ${prefix}/discovery but tests expect it at the prefix root (GET /api). Updated discovery route and .well-known/objectstack redirect to target prefix root.

Client feed routing

ObjectStackClient.feed methods called getRoute('feed') → /api/v1/feed/..., but feed is a sub-resource of data. Changed to getRoute('data') → /api/v1/data/{object}/{recordId}/feed, matching server-side routing.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
objectstack-play	Ready	Preview, Comment	Mar 31, 2026 7:07am
spec	Ready	Preview, Comment	Mar 31, 2026 7:07am

[Copilot]

Pull request overview

Fixes CI failures caused by TypeScript build errors, adapter/test mismatches around discovery routing, incorrect client feed routing, and ObjectQL metadata hydration issues (notably around SchemaRegistry object registration semantics).

Changes:

• Adjust SchemaRegistry.registerItem() calls in ObjectQL protocol to satisfy TypeScript when item type is inferred as unknown.
• Move adapter discovery responses to the API prefix root (e.g. GET /api) and update .well-known/objectstack redirects accordingly.
• Correct client feed routing to use the data route (/api/v1/data/{object}/{recordId}/...) instead of a standalone /feed route.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
packages/objectql/src/protocol.ts	Fix TS errors via keyField cast; adjust DB metadata hydration to route object records through registerObject()
packages/client/src/index.ts	Switch feed operations to use the data base route to match server routing
packages/adapters/sveltekit/src/index.ts	Serve discovery info at prefix root instead of /discovery
packages/adapters/nuxt/src/index.ts	Serve discovery at prefix root; update .well-known redirect target
packages/adapters/nextjs/src/index.ts	Serve discovery at prefix root; update .well-known redirect target
packages/adapters/hono/src/index.ts	Serve discovery at prefix root; update .well-known redirect target
packages/adapters/fastify/src/index.ts	Serve discovery at prefix root; update .well-known redirect target
CHANGELOG.md	Document CI/build/test fixes under Unreleased/Fixed

[Copilot]

The DB fallback hydration always uses SchemaRegistry.registerItem(...). For type === 'object', SchemaRegistry.getItem('object', ...) delegates to getObject() (objectContributors), so registering via registerItem won’t make future object lookups/listing work. Consider branching on record.type/request.type === 'object' and hydrating object records via SchemaRegistry.registerObject(...) (and pass namespace/package id from the sys_metadata row so FQNs and package scoping are preserved).

[Copilot]

Same as getMetaItems DB fallback: when request.type is 'object', hydrating via SchemaRegistry.registerItem(...) won’t populate the object registry used by getItem('object', ...)/getObject(). Align this path with loadMetaFromDb() by registering object-type records via SchemaRegistry.registerObject(...) instead, ideally using the sys_metadata row’s namespace and package id so FQN resolution remains correct.

[Copilot]

loadMetaFromDb() is reading record.packageId, but the persisted sys_metadata field is package_id (see SysMetadataObject). As written, this will almost always fall back to 'sys_metadata', losing package ownership. Also, SchemaRegistry.registerObject should likely receive the record’s namespace (or data.namespace) so objects are registered under the correct FQN rather than the short name. Consider using record.package_id ?? record.packageId and passing record.namespace (and for non-object types, pass the package id into registerItem(..., packageId) so listItems(type, packageId) works).

Suggested change

	if (record.type === 'object') {
	SchemaRegistry.registerObject(data as any, record.packageId || 'sys_metadata');
	} else {
	SchemaRegistry.registerItem(record.type, data, 'name' as any);
	const packageId = (record as any).package_id ?? record.packageId ?? 'sys_metadata';
	const namespace = (record as any).namespace ?? (data as any)?.namespace;
	if (record.type === 'object') {
	SchemaRegistry.registerObject(data as any, packageId, namespace);
	} else {
	SchemaRegistry.registerItem(record.type, data, 'name' as any, packageId);