Release Discipline and Versioning

Relevant source files

The following files were used as context for generating this wiki page:

• AGENTS.md
• CHANGELOG.md
• package.json
• README.md
• test/morph.test.ts

Release discipline and versioning within the oh-my-pi-plugin-morph project ensure that all shipped updates are synchronized across metadata, runtime constants, and user-facing documentation. This rigorous approach maintains a stable "release contract" with users and automated systems by adhering to established standards such as Keep a Changelog and Semantic Versioning.

The primary goal is to prevent desynchronization between the package version used by dependency managers and the internal version reporting used by the plugin runtime. This discipline extends to verification gates, including type checking and automated testing, which must be cleared before any release is finalized.

Sources: AGENTS.md:3-8, CHANGELOG.md:3-6

Versioning Standards and Synchronization

The project follows a strict rule for versioning: every shipped update must bump three specific locations simultaneously before a commit or push. This ensures consistency across the package's lifecycle from development to runtime.

Required Synchronization Points

1. package.json: Updates the version field, which serves as the primary package metadata for npm and other package managers.
2. src/config.ts: Updates the PLUGIN_VERSION constant, which is exported for runtime identification.
3. CHANGELOG.md: Moves entries from the [Unreleased] section to a new, dated heading corresponding to the version being released.

Sources: AGENTS.md:5-7, package.json:3

The Release Flow

The following diagram illustrates the mandatory steps required for a valid release update.

The diagram shows the sequential requirement to update metadata, runtime constants, and changelog history in a single release cycle.
Sources: AGENTS.md:5-6

Verification Gates

Before any version bump is committed, code and documentation must pass specific verification gates. These gates ensure technical accuracy and adherence to formatting standards.

Code Verification

For any functional changes, developers are required to run native repository scripts. The project deliberately avoids "inventing" new scripts (like a separate lint command) if they are not defined in the package.json.

Requirement	Command	Purpose
Type Integrity	bun run typecheck	Validates TypeScript types across the project.
Functional Logic	bun test ./test	Runs the automated test suite.

Sources: AGENTS.md:31-33, package.json:10-11

Documentation Verification

Markdown changes are subject to automated scans to prevent "formatting tells" that could interfere with AI processing or project standards.

• Docs Directory: Scanned via omp ttsr scan --json docs.
• Root Documents: Files like README.md or CHANGELOG.md require a filtered root scan for md-ai-formatting-tells to catch issues that single-file scans might miss.

Sources: AGENTS.md:36-39

Release History and Version Mapping

The project maintains a history of its version evolution, documenting features added and modified.

Version	Date	Significant Changes
0.3.1	2026-06-28	Compaction yields on local-only path; folds summary/prefix into Morph requests.
0.3.0	2026-06-27	Morph compaction handles manual /compact; added focus query forwarding; added abort signal racing.
0.2.0	2026-06-27	Added fastcompact tool; renamed tools to fast_edit, codebase_warpsearch, github_warpsearch.
0.1.0	2026-06-26	Initial port; added Morph Compact bridge and before_agent_start hints.

Sources: CHANGELOG.md:10-53

Integration with External SDKs

Versioning is also influenced by external dependencies, specifically the Morph SDK, which provides the underlying capabilities for the plugin's features.

This diagram shows the relationship between the project's versioning and its critical dependencies.
Sources: package.json:2-15

Conclusion

The release discipline of the oh-my-pi-plugin-morph project relies on the strict synchronization of version identifiers and the enforcement of verification gates. By mandating updates to metadata, runtime configuration, and the changelog simultaneously, the project ensures that its "release contract" remains intact for both human developers and automated agentic systems.

Sources: AGENTS.md:5-8, CHANGELOG.md:3-6