docs: complete DESIGN_CORE_REFACTOR.md with implementation status and retrospective

[Copilot]

The design doc header declared "✅ Completed" but Phase checklists and multiple sections still reflected the pre-implementation plan, not actual outcomes.

Updated the document to match the implemented state of the @objectql/core refactoring (PR #373):

• §8 Migration Plan — Marked 25 phase items as complete; only v5.0 release tag remains pending (Q4 2026)
• §4.1, §6.1–6.3, §7.1 — gateway.ts, ai/, protocol.ts were fully removed (original plan said keep); app.ts was transformed into a bridge class (original plan said remove); filter-translator.ts moved to plugin-query (original plan said remove)
• §4.4 — Replaced aspirational TARGET code with actual post-refactoring index.ts and kernel-factory.ts
• §1 Impact Summary — Actual metrics: 734 LOC (target was ~800), @objectstack/* ^3.0.2
• §9.1 Risk Matrix — Added Outcome column confirming all risks mitigated
• §10.3 — Replaced pre-refactoring API surface with post-refactoring file inventory

packages/foundation/core/src/        (734 LOC total)
├── index.ts            # 21 LOC  — Public API barrel
├── app.ts              # 168 LOC — Bridge class extending upstream ObjectQL
├── kernel-factory.ts   # 47 LOC  — Convenience kernel factory
├── plugin.ts           # 323 LOC — Plugin orchestrator
├── repository.ts       # 6 LOC   — Stub re-export
└── util.ts             # 169 LOC — Schema utilities

• §11 (new) — Implementation Retrospective: deviations table, final architecture diagram, lessons learned

---

💡 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)
objectql	Ready	Preview, Comment	Feb 13, 2026 7:22am

[hotlong]

能否彻底删除 @objectql/core ，直接使用 @objectstack/objectql @copilot

[Copilot]

能否彻底删除 @objectql/core ，直接使用 @objectstack/objectql @copilot

技术上可以，但需要较大范围的重构。当前 @objectql/core 仍提供以下不可直接替代的功能：

1. Bridge class (app.ts, 168 LOC) — 为 ObjectLoader 提供 MetadataRegistry 集成（文件系统加载 YAML → 同步到上游 SchemaRegistry）。上游 @objectstack/objectql.ObjectQL 没有 metadata 属性。

2. Plugin orchestrator (plugin.ts, 323 LOC) — 组合 QueryPlugin + ValidatorPlugin + FormulaPlugin，提供统一的 RuntimePlugin 入口。

3. Schema utilities (util.ts, 169 LOC) — toTitleCase(), convertIntrospectedSchemaToObjects() 等，被 @objectql/platform-node 直接引用。

当前依赖规模： 9 个 package.json + 17 个 TypeScript 文件有 @objectql/core 的直接导入。

如要彻底删除，需要：

• 将 util.ts 迁移到 @objectql/types 或 @objectql/platform-node
• 将 MetadataRegistry bridge 模式合并到上游 @objectstack/objectql 或 platform-node
• 将 plugin 组合逻辑移入各消费方或上游
• 更新所有 17+ 个导入点

建议作为单独的 issue 跟踪此工作（对应 v5.0 计划），不在本文档 PR 中实施。

[Copilot]

Pull request overview

Updates DESIGN_CORE_REFACTOR.md so it reflects the implemented @objectql/core refactor (PR #373), including completion status, actual architecture, and a retrospective.

Changes:

• Marks migration phases/items as completed and updates outcomes/metrics (LOC, deps, removed modules).
• Replaces “target”/planned sections with “actual post-refactor” API/file inventory and notes.
• Adds §11 retrospective (deviations, architecture diagram, lessons learned).

[Copilot]

This snippet uses new (ObjectKernel as any)(...), which is likely not copy/paste-compilable and makes the example hard to trust (if ObjectKernel is a type/interface, it’s not constructible; if it’s a class, the as any shouldn’t be needed). Consider updating the example to use the real constructible kernel class/export (whatever is actually instantiated in code) or add a brief note explaining why a cast is required here.

Suggested change

	return new (ObjectKernel as any)([
	return new ObjectKernel([

[Copilot]

The doc lists ObjectRepository as exported twice, which is confusing in an API inventory. Consider keeping a single export entry and adding a note that repository.ts exists specifically for path compatibility (or explicitly show that the path-compat export is via ./repository rather than repeating the same upstream export).

Suggested change

	export { ObjectRepository } from '@objectstack/objectql' // Context-scoped repository
	export { ScopedContext } from '@objectstack/objectql' // Context factory
	export { SchemaRegistry } from '@objectstack/objectql' // FQN-based object registry
	// NOTE: `repository.ts` exists only to preserve the legacy
	// import { ObjectRepository } from '@objectql/core/repository'
	// path. It simply re-exports this upstream symbol and does not add
	// a separate API surface.
	export { ObjectRepository } from '@objectstack/objectql' // Context-scoped repository (canonical source)
	export { ScopedContext } from '@objectstack/objectql' // Context factory
	export { SchemaRegistry } from '@objectstack/objectql' // FQN-based object registry

[Copilot]

The doc lists ObjectRepository as exported twice, which is confusing in an API inventory. Consider keeping a single export entry and adding a note that repository.ts exists specifically for path compatibility (or explicitly show that the path-compat export is via ./repository rather than repeating the same upstream export).

Suggested change

	export { ObjectRepository } from '@objectstack/objectql' // (also in repository.ts for path compatibility)
	// ObjectRepository is re-exported via ./repository solely for path compatibility with v3.
	// There is no additional direct export from the @objectql/core barrel.

[Copilot]

This hard-coded schedule date is likely to become stale over time. Since you already reference ROADMAP.md, consider removing the explicit “Q4 2026” here (or rephrasing to defer entirely to the roadmap) so the plan stays accurate with fewer touchpoints.

Suggested change

	- [ ] Tag v5.0 release (scheduled for Q4 2026 — see ROADMAP.md)
	- [ ] Tag v5.0 release (timeline per ROADMAP.md)