1.11.0 - Add deploy:run task selector with improved Windows interactive stdin handling

Added

• deploy:run task selector: Introduces a new deploy:run task selector/CLI entry point that discovers available Deployer tasks and allows selection (notably for interactive use). It executes the selected task with the appropriate argument construction.
• Unlock retry support (interactive): Adds support for re-running deployment after an interactive unlock flow, when the user confirms the retry.

Changed

• Windows interactive stdin handling: Improves how interactive stdin is preserved and forwarded on Windows by using native IO instead of relying on Symfony Process stdin behavior, which could poll or mishandle input.
• Test determinism improvements: Updates tests to derive PM2 numeric collision behavior from the executing Node process.
• Test/fixture alignment for Windows: Preserves Windows fixture arguments and verifies the rebuilt CLI appropriately.
• More isolated, parallel test execution: Runs Deployer tests in parallel while isolating subprocess environments to reduce cross-test interference.

Fixed

• Prevent Windows interactive deadlocks/blocks: Fixes interactive Deployer behavior on Windows by ensuring interactive input is inherited/forwarded directly to the Deployer subprocess, reducing the chance of deadlocks or failing reads.

Testing

• Reproduce Windows stdin failures in tests: Adds/adjusts tests to reproduce Windows Deployer stdin failures using live test events.

Documentation

• README badge standardization: Standardizes README badges and keeps release-linked values consistent.

Internal Maintenance

• Style/formatting: Formats the Node collision fixture according to the configured Rector rules.
• Integration-only merge: Includes integration work by merging the origin/1.x branch into the 1.x line (no additional functional changes are explicitly described beyond the merged commits).

Compatibility & Migration

• Additive feature: The new deploy:run command is an additive capability intended to complement existing deploy usage.
• Windows runtime behavior change: Interactive Deployer flows on Windows should behave more reliably due to the stdin forwarding changes; no public API changes are indicated.
• Migration steps: No required migration steps are described. If you want to use the new selector/retry workflow, update your CLI usage/docs/scripts accordingly.

1.10.0 - Support multiple centered README description paragraphs

Added

• Multi-paragraph centered README descriptions: The README head rendering now supports multiple centered description paragraphs instead of a single description string.
• Multi-line description API: The README head model introduces a multi-line description accessor (descriptionLines()), allowing callers to provide description content as lines/paragraphs.
• Paragraph-by-paragraph rendering: The README head writer renders each paragraph as its own centered <p> block.
  • Inline Markdown is converted per line/paragraph.
  • HTML is escaped for safety while link handling remains appropriate for Markdown rendering.
  • Whitespace is normalized during rendering.
  • Only the first paragraph includes id="maintainer-description"; subsequent paragraphs are rendered without that ID.

Changed

• Breaking/compatibility considerations for description handling:
  • The rendering behavior changes from the previous single-description approach.
  • Callers relying on the old withDescription(?string) semantics (or expecting a single description string) should update to the new multi-line model.
  • If you previously provided one string and relied on "\n\n" paragraph joining behavior externally, you may now need to supply description content via the new line/paragraph API (for example via string arrays or incremental APIs like appendDescriptionLine()).
• Output formatting differences:
  • The writer no longer uses the previous single-description HTML escaping path.
  • Exact HTML/Markdown rendering may differ from earlier versions, especially around inline formatting and paragraph boundaries.

1.9.0 - Clean up README badge duplication and introduce versioned README head markers

Changed

• README badge cleanup: Removed duplicated Packagist badges from the repository README so only a single Packagist badge is shown.
• Maintainer header cleanup: Removed a duplicated Packagist badge from the maintainer header area of the README to keep badge presentation consistent across the README.

Added

• Versioned README head management: Added a new mechanism to manage the README “head” section using versioned release markers (delimited start/end region markers such as MAINTAINER:README_HEAD start/end).
  • This enables more reliable, structured replacement of the README header content during release creation.
  • The README header can be regenerated in a consistent way (e.g., including optional branding like a logo, title/description, and badges reflecting release/version state).

Compatibility / Migration Notes

• If you previously relied on an older README header/badge setup that depended on the previous managed structure (e.g., older anchors or non-marker-based placeholders), migrate to the new marker-delimited README head management approach.
• Header content is now controlled by the marker-defined region, so updating release/README generation tooling should target these versioned markers rather than the prior approach.

1.8.0 - Optionally sync package.json version during release creation

Added

• Added an interactive option to update the root package.json version to match the selected release version during frontend release creation.
  • The user is prompted: “Update package.json to {$selectedVersion}?”
  • The prompt defaults to false and the update only proceeds when the updater determines it is safe (canUpdate($projectRoot)).
• Introduced App\Support\Release\PackageJsonVersionWriter to safely write package.json updates.
• Added GitWorkingTree::isTracked() to verify package.json is tracked by git before attempting an update.

Changed

• Updated app/Commands/Versioning/CreateReleaseCommand.php to include the new confirmation prompt and guard the update behind safety checks.
• Improved release-side README version badge handling:
  • Better support for repositories that contain multiple existing managed version badges.
  • When multiple matching managed badges exist, the last match is replaced and duplicates are removed.

Testing

• Extended feature tests to cover:
  • The new confirmation prompt behavior.
  • Updating package.json and src/ProjectVersion.php only when the user confirms.
  • Improved failure messaging/rollback behavior, including ensuring the repository remains clean and package.json is unchanged when preparation fails.

User impact / Compatibility

• Behavior change: release:create may modify the root package.json version only if the user confirms the prompt and the update writer determines the update is safe.
• If the repository layout is unsuitable (e.g., package.json is missing, symlinked, or not tracked by git), the update will not be performed.
• README updates: if multiple managed version badges were present, only the last matching one is updated and earlier duplicates are removed—no additional user action is required beyond reviewing the README changes.

1.7.0 - Fix PHAR bundled command discovery and path handling on Windows

Fixed

• Windows: register bundled commands for PHAR

  • Bundled PHAR CLI command discovery/registration is now explicitly performed so command-name resolution behaves consistently on Windows.
  • User impact: Windows users running the bundled PHAR should no longer see commands missing from the CLI.
  • Compatibility/Migration: No public API changes; this corrects packaged command registration behavior.

• PHAR: normalize archive paths and improve distributed PHAR reliability

  • PHAR archive path handling is normalized to avoid platform-specific path separator issues (e.g., Windows backslashes) that can break PHAR-internal path resolution.
  • Added tests covering distributed PHAR packaging/startup behavior, including smoke coverage for loading bundled defaults.
  • User impact: More reliable PHAR execution across platforms, especially for distributed PHAR scenarios (notably on Windows).
  • Compatibility/Migration: No functional API changes; consumers should not rely on non-normalized Windows separators inside phar:// paths.

• Windows: resolve bundled config paths in Maintainer PHAR

  • Fixed Windows-specific resolution of bundled configuration asset paths inside the Maintainer PHAR.
  • User impact: Bundled configuration assets are located correctly on Windows, restoring expected behavior for configuration publishing/maintenance tasks.
  • Compatibility/Migration: No public API changes; this corrects internal asset path resolution for Windows.

1.6.0 - Improve documentation guidance for upcoming 1.6.0 changes

Documentation

• Updated documentation in CHANGELOG/docs to reflect upcoming 1.6.0 changes.
• Added/clarified guidance for maintainers and users, including:
  • Documented fixes related to AI commit prompt truncation to help avoid provider context-length failures.
  • Noted an adjustment to the quality-fix execution order: Rector before Pint.
  • Updated README version badge markup/behavior, including:
    • Marker-based migration behavior.
    • Single-line badge formatting.
  • Documented the underlying behavior of README badge maintenance—how version badges are inserted/updated and what users should expect.

No functional code changes were included in this release; this update is focused on improving clarity and forward guidance for the 1.6.0 transition.

1.5.2 - Enforce strict changelog entry types

Changed

• Strict structured output for AI changelog entries: The release changelog generation now requests strict structured output from AI providers, so only supported Conventional Commit type values are produced.

  • If an AI provider returns an invalid changelog entry type, the release process now aborts with an error.
  • The error message includes:
    • the originating commit identifier (commit hash),
    • the invalid type value received, and
    • the full list of allowed type values.

• Strict agent execution: ReleaseChangelogAgent now runs in strict mode (via #[Strict], in addition to the existing #[UseCheapestModel]). This improves validation/acceptance behavior and reduces the likelihood of non-conformant structures being used.

• Improved validation diagnostics: LaravelAiReleaseChangelogGenerator now throws a RuntimeException with more specific context when validation fails due to an invalid type:

  • commit hash,
  • a debug/truncated representation of the returned type,
  • and the full expected set self::TYPES.

Documentation

• Changelog configuration guidance was updated to reflect that the release process requests strict structured output from AI providers.

Testing

• Unit tests were expanded to verify:
  • the generator requests a strict OpenAI JSON schema (strict: true) and constrains entries[].type to the allowed enum:
    • feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
  • invalid type values (unknown category, null, or non-string) are rejected and cause generate() to throw a RuntimeException that includes the commit hash, the invalid value, and the expected allowed types.

Compatibility / Migration

• This is primarily a stricter validation change.
• If your AI provider/workflow previously returned changelog type values outside the allowed set, the release process will now fail early instead of accepting them.
• No public configuration keys or APIs are described as changed; migration is only relevant for workflows that relied on previously non-compliant AI outputs.

1.5.1 - Preserve PHAR template indentation and layout

Fixed

• Ensured packaged PHAR distributions keep the exact indentation and layout of publishable template files.
  • Updated the PHAR distribution/publishing process so config/maintainer.php and config/maintainer_secrets.php are packaged as unmodified template files.
  • Concretely, these files are now included via a dedicated files-bin group in box.json (instead of the broader files set), helping prevent whitespace/formatting changes during packaging.

Testing

• Refined and expanded unit test coverage in tests/Unit/ComposerManifestTest.php to prevent regressions.
  • Verifies box.json no longer includes directories for config/resources.
  • Confirms config/template splitting between boxManifest['files'] (compacted entries) and boxManifest['files-bin'] (unmodified template entries).
  • Asserts PHAR contents preserve byte-for-byte formatting for:
    • config/maintainer.php
    • config/maintainer_secrets.php
    • resources/pint.json

Compatibility / Migration

• No source-level migration is required for consumers.
• This is a packaging/publishing behavior fix: if you previously depended on how these template files were formatted when installed from the PHAR, re-check those assumptions.

1.5.0 - Contract-based code-quality workflows with new fix/check CLI

Summary

This release switches code-quality execution to a contract-based workflow model and updates the CI/menu UX to split the former unified quality flow into separate quality:fix and quality:check commands.

Added

New contract-based quality types

New marker interfaces were added under App\Quality\Contracts to represent quality “contract” surfaces (used for selection/discovery and container binding), including:

• RunsPestCheck
• RunsPhpStanCheck
• RunsPintCheck
• RunsPintFix
• RunsRectorFix
• RunsVitePlusCheck

New CLI commands

Two new commands are introduced and wired to the existing quality.fix / quality.test configuration workflows:

• quality:check (app/Commands/CodeQuality/RunCheckCommand.php)
  • Runs CI code-quality checks.
  • Uses shared execution workflow logic.
• quality:fix (app/Commands/CodeQuality/RunFixCommand.php)
  • Runs fix workflows and is able to create a commit when appropriate.
  • Can run checks as part of the fix flow.
  • Supports --tool=* to run only selected configured tools.

Shared workflow command

A new shared abstract workflow command RunCodeQualityWorkflowCommand implements the core execution flow, including:

• Validating the project root.
• Loading configured QualityCommand contract implementations from maintainer configuration (via subclass-provided config).
• Interactive tool selection.
• Per-project tool availability checks (with warnings and skips when a tool isn’t available for the root).
• Resolving tool-specific configuration declared by each tool.

Container bindings for contract types

New container bindings were added so the framework can resolve contract types to their concrete implementations, including (at minimum):

• RunsPintFix
• RunsRectorFix
• RunsPestCheck
• RunsPintCheck
• RunsPhpStanCheck
• RunsVitePlusCheck
• RunsVitePlusTest
• RunsVueTscCheck

Changed

CI/menu workflow UX: split quality into quality:fix and quality:check

The former single quality flow is replaced in user selection UX with:

• quality:fix
  • Defaults include Pint, Rector, and the package script invoking the fix workflow.
• quality:check

This changes how users run quality tooling:

• Instead of selecting individual tools via the previous multiselect/CI menu behavior, users now select quality:fix or quality:check.
• Users can optionally narrow tool execution using --tool=*.

Quality tool selection/discovery moves to contracts

Quality tool selection and discovery now rely on contract implementations rather than the older console command classes.

Migration impact (configuration):

• Any quality.fix / quality.test configuration entries that referenced legacy App\Support\Quality\Commands\... must be migrated to the corresponding Runs... contract FQCNs.

Improved Versionable class discovery

Versionable class discovery was updated to use:

• the production Composer autoload.classmap, and
• direct production PSR-4 namespaces,

so that exact-file exports remain correct without broadly expanding namespaces.

Release automation strengthened

Release creation now:

• runs quality:fix non-interactively (the release command fails if it fails), and
• conditionally runs quality:check non-interactively based on shouldRun().

A helper preserves prompt/input interactivity after --no-interaction => true.

Maintainer version constant

The maintainer version constant is bumped to 1.5.0.

Package publishing encryption/SSH email adjustment

Publishing behavior is adjusted to skip Maintainer SSH key email generation for Laravel package project types, avoiding a dependency on application encryption key requirements.

Fixed

• Introduced contract-based workflow execution and “fix/check” wiring corrections so quality tooling resolves and runs via the new contract-based surfaces.

Removed

Deleted legacy quality command behavior

The old LaravelZero console command app/Commands/CI/RunQualityCommand.php was deleted.

This included the former interactive/behavioral features such as:

• quality {--tool=*} command handling,
• tool config creation,
• extra-arg derivation from maintainer configuration,
• and optional git commit prompting.

Compatibility impact:

• Any external consumers or automation invoking that removed command/behavior will break.
• Update scripts/integration to use quality:fix and/or quality:check instead.

Migration / Compatibility Notes

1. Update configuration FQCNs: migrate any quality.fix / quality.test entries from:
   • App\Support\Quality\Commands\...
     to the new:
   • Runs... contract FQCNs (e.g., RunsPintFix, RunsPintCheck, RunsRectorFix, etc.).
2. Update CLI usage:
   • Replace usages of the removed quality {--tool=*} behavior with quality:fix and/or quality:check.
3. Release behavior:
   • Expect release automation to enforce non-interactive quality:fix runs and fail releases when fixes fail.

1.4.0 - Make interactive commit message generation deterministic and reviewed before committing

Changed

• Deterministic interactive prompts in tests/CI (Windows-safe)

  • Refactored the commit/release title generation and commit-message editing flows used during tests to remove platform-dependent prompt fallback behavior.
  • Interactive decisions for review vs. generation mode and push-to-origin are now made deterministic by explicitly injecting prompt behavior, instead of relying on OS-specific prompt resolution.
  • User impact: Interactive CLI prompting becomes more predictable in test and CI environments, with no CLI surface-area changes.

• Review generated commit messages before committing

  • Added a new interactive step in the commit command: “Review the generated commit message”.
  • Generated commit messages are now always routed through a reviewer UI (a textarea prompt) so users can edit the suggested message before it is finalized.
  • Manual commit messages also use the same editing/review flow for consistency.
  • User impact: In AI modes, commits are no longer finalized immediately after message generation; users must explicitly review/edit the suggested message.
  • The commit-message editor enforces validation: the resulting message must be non-empty after trimming.

Internal Maintenance

• Refactored interactive commit flows to use injected workflow/UX services:
  • CommitWorkflowPrompts (for diff review, message mode selection, and push-to-origin decisions)
  • CommitMessageReviewer (for editing and validating commit message text)
• For non-manual AI modes, commit-message generation still occurs (including any optional additional context for AiWithContext), but the final commit message is taken from the user-reviewed/edited result rather than being used directly.

Compatibility / Migration

• No migration required.
• Behavioral difference: users will see an additional interactive prompt when generating commit messages (AI modes) to review/edit the suggested message.
• CLI/API signatures are not changed based on the provided release summary.