GSD Cursor Model Profiles (gsd-cursor) — EoS registry entry

[clezcoding]

Repository: https://github.com/clezcoding/gsd-cursor — A GSD EoS that adds six researched Cursor runtime profiles (max / hybrid / value / budget / frontier / openweight), writes current and legacy tier-map surfaces, routes all six GSD phases, validates local model availability, and restores prior managed settings on uninstall without modifying gsd-core. Current release: v1.1.0. Interface points: model + state; profile: declarative-cli; protocol: v1.

[clezcoding]

🧭 Expansion plan — gsd-cursor as the complete Cursor EoS host plugin

Important

This comment creates the durable public continuity record for expanding the existing gsd-cursor EoS entry into the complete out-of-tree Cursor host integration. It records the intended contract, migration order, release gates, and split-PR strategy before implementation begins.

✨ Outcome

The existing clezcoding/gsd-cursor project will grow from its current model + state profile integration into the single complete Cursor EoS host plugin.

The intended end state is:

• one Cursor package
• one EoS registry entry
• one installation path
• the GSD orchestration engine remains in gsd-core
• Cursor-specific host integration code moves out of gsd-core and is maintained in clezcoding/gsd-cursor

This follows the environment-adoption direction in Discussion #2749, the takeover/continuity guide, and the host-plugin authoring guide.

---

🤝 Coordination record

In the Discord follow-up, Trekkie clarified that:

“if you want to take over, you need to take it completely over”

The accompanying direction was to:

1. merge the existing gsd-cursor work with the Cursor integration currently in core;
2. port the Cursor-specific implementation into the external module;
3. add meaningful tests;
4. release the external module;
5. handle the registry update and the core removal as separate pull requests;
6. avoid making Cursor users install multiple overlapping capabilities.

Because gsd-cursor is already the registered ID and the existing repository is already maintained by the same author, I interpret “one package” as expanding the existing gsd-cursor ID and repository, not introducing a second Cursor package or duplicate registry entry.

Note

This is not a T1 ownership repoint: id, repo, and author remain unchanged. The registry work will be a normal Changed scope/contract update after the expanded plugin has been released and verified. The coordinated handoff concerns the first-party Cursor implementation being moved out of core.

If the intended ID strategy differs, please correct that interpretation here before the registry PR is opened.

---

📍 Current → planned registry state

Surface	Current state	Planned state
Registry ID	gsd-cursor	unchanged
Repository	clezcoding/gsd-cursor	unchanged
Author	clezcoding	unchanged
Current release	v1.1.0	new immutable release after parity validation
Interface points	model, state	command, dispatch, model, hooks, state, artifact
Current role	Cursor model profiles	complete Cursor EoS host integration, including the existing model profiles
Core baseline	partial external integration + first-party Cursor runtime	current v1.10.0 Cursor contract ported out of core
Earliest core target	—	v1.11.0, subject to implementation and review readiness

---

📜 Contract snapshot to preserve

The implementation baseline is the current Cursor capability descriptor on next, version 1.10.0.

The external plugin must preserve the currently declared Cursor behavior:

Host-integration axes

Axis	Contract
embeddingMode	imperative
commandSurface	slash-file
modelMode	passive
hookBus	host
stateIO	filesystem
transport	mcp
runtime	node
effortSurface	undocumented

Dispatch behavior

• named dispatch
• nested dispatch
• maximum nested depth of 2
• background execution
• background dispatch
• full subagent toolkit
• harness-worktree isolation through --worktree

Cursor artifacts and host behavior

• global and project-local skill projection

• global and project-local agent projection

• flat Cursor nesting

• recursive skill conversion

• Cursor-specific frontmatter conversion

• .cursor/hooks.json integration

• managed lifecycle events:

  • sessionStart
  • preToolUse
  • postToolUse
  • stop
  • subagentStart
  • subagentStop

• no shared settings writes

• no duplicate shared-hook installation

• no settings UI or update-banner command

• cleanup of retired .cursor/commands/gsd-*.md artifacts

• preservation of the current cursor-agent reviewer behavior, or an explicitly reviewed continuity path that ensures the --cursor review surface is not stranded by the core removal

The existing six Cursor model profiles and their safe restore behavior remain part of the package; they are merged into the complete plugin rather than replaced.

---

🧱 Implementation and landing sequence

1. Port the current Cursor implementation

• Lift the current Cursor descriptor and host behavior from v1.10.0/next.
• Move Cursor-specific adapters, conversion behavior, artifact layout, hook handling, dispatch configuration, state handling, and migration cleanup into clezcoding/gsd-cursor.
• Bind all six host-interface points.
• Import only from the public @opengsd/gsd-core/sdk entry.
• Do not depend on private gsd-core modules or source-file paths.
• Keep the GSD orchestration engine in gsd-core.
• Preserve the existing model-profile functionality and exact uninstall restoration semantics.

2. Prove parity and migration safety

• Descriptor/schema validation.
• SDK handshake and protocol-version validation.
• Contract tests for all six interface points.
• Global and project-local install tests.
• Named, nested, and background dispatch tests.
• Maximum-depth and worktree-isolation tests.
• Tests for all six managed hook events.
• Skill and agent conversion/projection tests.
• Model-profile installation and local-model validation tests.
• Update and --reapply tests.
• Migration test that retires legacy .cursor/commands/gsd-*.md artifacts without removing unrelated user files.
• Exact backup/restore and uninstall tests.
• Reviewer continuity test for the current Cursor review surface.
• End-to-end smoke test using isolated temporary configuration directories so tests never touch a developer’s live Cursor or GSD configuration.

3. Publish the external release first

• Choose the release version after compatibility review.
• Pin and verify the supported GSD engine range.
• Publish an immutable GitHub release.
• Verify the registry install command from a clean environment.
• Verify update, reapply, and uninstall from a clean environment.
• Publish migration and rollback notes.
• Record the exact release tag and commit used for the registry entry.

4. Open the registry PR separately

The registry PR will:

• update exactly the existing gsd-cursor object in docs/registries/eos.json;
• retain the same id, repo, author, and this Discussion URL;
• describe the complete released integration;
• list all six interface points;
• record the validated SDK-derived profile and authoritative axes;
• pin copy-pasteable install and uninstall commands to the tested release;
• retain protocolVersion;
• regenerate the registry Markdown with npm run gen:registry;
• pass npm run validate:registry and the registry drift checks;
• include a Changed changeset;
• avoid unrelated code or registry-entry changes.

5. Open the core removal/deprecation PR separately

Only after the external release and its registry metadata are reviewable, the core PR will:

• remove the first-party Cursor host descriptor and Cursor-only implementation branches that have been ported;
• preserve shared engine and SDK behavior;
• update tests, fixtures, generated surfaces, and documentation affected by the removal;
• include a clear migration note pointing users to gsd-cursor;
• prevent duplicate or stale Cursor installations;
• demonstrate parity with the released external plugin;
• keep the reviewer surface working through an explicitly reviewed continuity path;
• target v1.11.0 only if all implementation, migration, and review gates are satisfied.

---

✅ Acceptance gates

The transition is ready to land only when all of the following are true:

1. No split installation: Cursor users install one package, not separate model-profile and host-integration packages.
2. No behavioral regression: the released plugin covers the current v1.10.0 Cursor contract.
3. No data loss: install, update, reapply, migration, and uninstall preserve unrelated user configuration.
4. No private-core dependency: the plugin consumes only the public SDK.
5. No release-before-proof: the registry never points at an untested branch or mutable reference.
6. No removal-before-replacement: core removal does not land before a functional, released, reviewable external replacement exists.
7. No bundled governance change: registry update and core removal remain separate PRs.
8. No reviewer regression: the current Cursor reviewer path remains available or receives an explicitly approved migration.
9. No duplicate ID or package: the existing gsd-cursor continuity path remains the single user-facing entry.
10. Fail-closed compatibility: unsupported SDK/protocol combinations produce a clear error rather than silently degrading.

---

🚫 Explicit non-goals

• No second Cursor EoS entry.
• No second package users must install alongside gsd-cursor.
• No rewrite of the GSD orchestration engine.
• No silent redesign of the inherited Cursor behavior during extraction.
• No hand-edited generated registry Markdown.
• No removal of the working core integration before the external release proves parity.
• No unrelated registry, capability, or documentation changes in either PR.

---

🔗 Continuity

This Discussion remains the long-term public record for:

• the existing model-profile integration;
• the complete Cursor host-plugin expansion;
• release and migration evidence;
• registry review;
• future compatibility reports and maintainer updates.

Implementation PRs and release notes will link back here so the transition remains auditable from intent through release and core deprecation.