Kernel Upgrade: ExecutionContext propagation, per-object hooks, middleware chain, plugin-security

[Copilot]

Implements the full execution context propagation chain specified in docs/objectql_roadmap.md — bridging the gap between plugin-auth (authentication) and data operations (authorization/context). Previously, HookContextSchema.session, PermissionSetSchema, and RowLevelSecurityPolicySchema were defined in spec but had zero runtime wiring.

Spec: ExecutionContext + Data Engine Context

• New ExecutionContextSchema (packages/spec/src/kernel/execution-context.zod.ts) — userId, tenantId, roles, permissions, isSystem, accessToken, transaction, traceId
• BaseEngineOptionsSchema with optional context field; all 6 DataEngine option schemas extend it
• Added ./security subpath export to @objectstack/spec

ObjectQL Engine: Hooks, Middleware, Context

• Per-object hooks with priority: registerHook(event, handler, { object?, priority? }) — replaces flat Record<string, HookHandler[]> with Map<string, HookEntry[]>, sorted by priority, with object-match filtering
• Middleware chain (onion model): registerMiddleware(fn, { object? }) wraps all CRUD operations
• Context propagation: options.context → HookContext.session + HookContext.transaction in all methods
• MetadataFacade: injectable wrapper over SchemaRegistry, registered as metadata service
• ObjectRepository + ScopedContext: engine.createContext({ userId, tenantId }).object('user').find()

// Context flows from HTTP layer to data operations
const results = await engine.find('account', {
  filter: { status: 'active' },
  context: { userId: 'u1', tenantId: 'org1', roles: ['sales'] }
});

// Or via scoped context
const ctx = engine.createContext({ userId: 'u1', tenantId: 'org1' });
const accounts = ctx.object('account');
await accounts.find({ filter: { status: 'active' } });

ObjectQLPlugin: Audit Hooks + Tenant Middleware

• Auto-stamp created_by/modified_by/created_at/modified_at/space_id on insert/update (priority 10)
• Auto-fetch previousData for update/delete hooks (priority 5)
• Tenant isolation middleware: auto-inject space_id filter for non-system operations with tenantId

AuthPlugin

• Registers auth middleware on ObjectQL engine in start() (placeholder for session resolution via AsyncLocalStorage)

New Package: @objectstack/plugin-security

• PermissionEvaluator — resolves PermissionSets from roles, checks CRUD permissions (most-permissive merge)
• RLSCompiler — compiles using expressions (field = current_user.prop, field IN (current_user.arr)) into ObjectQL filters
• FieldMasker — strips non-readable fields from results, strips non-editable fields from writes
• SecurityPlugin — registers as engine middleware: RBAC check → RLS filter injection → field masking

All changes are backward compatible — context is optional everywhere, existing tests unmodified and passing.

Original prompt

On objectql_roadmap.md, 参考此文件中的要求，修改代码

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
objectstack-play	Ready	Preview, Comment	Feb 10, 2026 4:19pm
spec	Error		Feb 10, 2026 4:19pm

[Copilot]

Pull request overview

This PR implements a comprehensive kernel upgrade that introduces execution context propagation, per-object hooks with priority, middleware chain (onion model), and a new security plugin. It bridges the authentication layer (plugin-auth) with data operations by flowing user identity, tenant context, and permissions through the entire stack.

Changes:

• Adds ExecutionContext protocol to spec package with userId, tenantId, roles, permissions, and transaction support
• Refactors ObjectQL engine to support per-object hooks with priority and middleware chain wrapping all CRUD operations
• Introduces MetadataFacade as injectable wrapper over SchemaRegistry
• Adds ObjectRepository and ScopedContext for ergonomic context-bound data access
• Implements SecurityPlugin with RBAC evaluation, RLS filter compilation, and field-level security
• Adds built-in audit hooks for auto-stamping created_by/modified_by and tenant isolation middleware

Reviewed changes

Copilot reviewed 19 out of 20 changed files in this pull request and generated 12 comments.

Show a summary per file

File	Description
packages/spec/src/kernel/execution-context.zod.ts	Defines ExecutionContext schema with user/tenant/permissions/transaction fields
packages/spec/src/data/data-engine.zod.ts	Adds BaseEngineOptions with optional context to all 6 CRUD operation schemas
packages/spec/package.json	Exports new ./security subpath for permission/RLS schemas
packages/objectql/src/engine.ts	Refactors hooks to Map-based with priority, adds middleware chain, propagates context through all operations, adds ObjectRepository/ScopedContext
packages/objectql/src/metadata-facade.ts	Provides injectable interface over SchemaRegistry for metadata service
packages/objectql/src/plugin.ts	Registers MetadataFacade, adds audit hooks and tenant isolation middleware
packages/plugins/plugin-auth/src/auth-plugin.ts	Registers placeholder auth middleware on ObjectQL engine
packages/plugins/plugin-security/*	New plugin with PermissionEvaluator, RLSCompiler, FieldMasker, and SecurityPlugin

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

[Copilot]

The audit hook for beforeInsert does not handle array data correctly. When hookCtx.input.data is an array (bulk insert), the code treats it as a single object and tries to stamp audit fields on the array itself rather than on each element.

This will fail to add audit fields (created_by, modified_by, etc.) to bulk insert operations. The hook should check if data is an array and iterate over each element to apply the audit stamps.

[Copilot]

The RLS compiler's expression parsing is overly simplistic and could lead to security vulnerabilities or incorrect access control.

Issues:

1. Only supports basic patterns (field = current_user.property, field IN (...), field = 'literal')
2. No validation that the expression is safe (could contain malicious SQL if extended)
3. Returns null for unsupported expressions without logging or error - this could silently bypass security policies

Consider:

• Adding validation to reject potentially unsafe expressions
• Logging warnings when policies cannot be compiled
• Documenting the subset of RLS expressions currently supported
• Adding comprehensive test coverage for expression parsing edge cases

[Copilot]

The tenant isolation middleware only applies filters to read operations (find, findOne, count, aggregate) but does NOT enforce tenant isolation on write operations (insert, update, delete).

This is a critical multi-tenant security gap:

1. Users can insert records with arbitrary space_id values, potentially creating records in other tenants
2. Users can update/delete records in other tenants by manipulating the filter to bypass space_id checks
3. The audit hook stamps space_id on insert (line 148), but this occurs AFTER middleware, so malicious users could override it

Consider:

• Adding tenant validation to update/delete operations to prevent cross-tenant modifications
• Validating that inserted records have the correct space_id AFTER the audit hook runs
• Moving tenant enforcement to middleware that runs BEFORE hooks to prevent bypass

[Copilot]

The ObjectRepository methods don't preserve all query options when merging with context. For example, in the find method (line 941-946), the spread operator ...query comes BEFORE context: this.context, which means if a caller passes a context in the query parameter, it will be overwritten by the repository's context.

This could lead to confusion where a developer explicitly passes context but it gets silently ignored. Consider either:

1. Throwing an error if query contains a context (to prevent silent overwrites)
2. Merging contexts explicitly with clear precedence rules
3. Documenting that the repository's context always takes precedence

[Copilot]

The new ExecutionContext propagation, middleware chain, per-object hooks, and ScopedContext/ObjectRepository features lack test coverage in the ObjectQL engine tests.

While ExecutionContextSchema has unit tests in the spec package, there are no integration tests verifying:

1. Context propagation through find/insert/update/delete operations
2. Middleware chain execution order and context passing
3. Per-object hook filtering and priority ordering
4. ScopedContext and ObjectRepository API behavior
5. Interaction between middleware and hooks with contexts

These are fundamental architectural changes that should have comprehensive test coverage before being merged. Consider adding integration tests to verify the execution context flows correctly through the entire stack.

[Copilot]

The SecurityPlugin lacks test coverage. A new plugin implementing critical security features (RBAC, RLS, field masking) should have comprehensive unit tests to ensure:

1. Permission evaluation works correctly with different permission sets
2. RLS filter compilation produces correct query filters
3. Field masking properly removes non-readable fields
4. Edge cases like empty permission sets, missing metadata, and malformed policies are handled

Consider adding tests to verify the security guarantees before this code reaches production.

[Copilot]

The error handling in the security middleware silently swallows exceptions when resolving permission sets. On line 82-85, if an error occurs during resolvePermissionSets, the code logs nothing and continues without security checks.

This is a critical security issue: if the metadata service throws an error, all subsequent operations bypass permission checks entirely. An attacker could potentially trigger metadata errors to gain unauthorized access.

Consider:

• Logging a warning when permission resolution fails
• Making this behavior configurable (fail-open vs fail-closed)
• In production environments, default to fail-closed (deny access on errors) rather than fail-open

Suggested change

	// If metadata service is misconfigured, log and continue without permission checks
	// rather than blocking all operations
	// If metadata service is misconfigured, decide whether to fail-open or fail-closed.
	// In production (NODE_ENV === 'production'), we default to fail-closed (deny access).
	// In non-production environments, we log and continue without permission checks.
	const isProduction = process.env.NODE_ENV === 'production';
	ctx.logger?.warn?.(
	`[Security] Failed to resolve permission sets for roles [${roles.join(', ')}] ` +
	`on operation '${opCtx.operation}' for object '${opCtx.object}'. ` +
	(isProduction
	? 'Denying access (fail-closed).'
	: 'Continuing without permission checks (fail-open).'),
	{ error: e }
	);
	if (isProduction) {
	throw new Error('[Security] Unable to resolve permission sets; access denied.');
	}

[Copilot]

The security middleware skips permission checks when roles.length === 0 && !opCtx.context?.userId. This creates a potential security bypass: unauthenticated users with no roles can access data without permission checks.

While the comment mentions "the auth middleware should handle authentication separately", relying on another middleware for security is risky:

1. If auth middleware is not installed or misconfigured, this allows unauthorized access
2. Middleware execution order matters - if security runs before auth, this bypass activates
3. Anonymous access should be an explicit, documented feature, not a fallback behavior

Consider:

• Making anonymous access behavior configurable (with secure defaults)
• Logging when operations proceed without authentication
• Documenting the dependency on auth middleware and middleware ordering requirements

[Copilot]

The permission resolution logic is fragile and could fail to load permission sets correctly. On line 100, the code calls metadataService.list?.('permissions') which:

1. Uses optional chaining (?.) suggesting the method might not exist
2. Passes 'permissions' as the type, but there's no guarantee this type exists in the metadata registry
3. Returns an empty array on failure without logging, making debugging difficult
4. Assumes permission sets have a name field that matches role names exactly

This makes the permission system brittle:

• If permission sets are registered under a different metadata type, they won't be found
• No validation that permission sets conform to the expected schema
• Silent failures make it hard to diagnose permission issues in production

Consider adding validation, error logging, and documentation about the expected metadata structure.

[Copilot]

The middleware execution happens OUTSIDE the hook execution in the find/insert/update/delete/count/aggregate operations. Looking at the structure:

executeWithMiddleware(opCtx, async () => {
  // Hooks run here
  triggerHooks('beforeX', hookContext)
  // Driver call
  result = await driver.operation(...)
  // After hooks
  triggerHooks('afterX', hookContext)
})

This means middlewares wrap hooks. However, the SecurityPlugin modifies opCtx.ast (the query AST) in middleware, while hooks receive hookContext.input.ast. If a hook modifies the AST, those changes might not be seen by security middleware that already ran, or vice versa.

Additionally, the audit hooks (lines 139-195 in plugin.ts) stamp fields on hookCtx.input.data which happens INSIDE the middleware executor, so tenant validation middleware cannot validate the stamped values since it runs OUTSIDE.

This creates potential race conditions and bypass opportunities. Consider documenting the middleware/hook execution order and ensuring security-critical validations happen at the right layer.