🚀 Release v2.1.0

✅ Custy v2.1.0 — Cross-Project Compatibility Release

Custy v2.1.0 expands release automation beyond repositories that use an
app/-based Python layout. Custy can now start, initialize, validate, and
resolve version metadata across Python, Node.js, mixed, PHP, documentation-only,
and generic repositories without requiring placeholder directories or files.
The release also strengthens changelog template and repository-link resolution,
message backups, configured-remote workflows, CLI failure handling, dry-run
safety, configurable message editors, interactive Docker workflows, and
project-wide code quality. Commit-message validation now adapts to projects
with or without Commitizen, and Git-hook failures retain the output developers
need to diagnose them. Standalone push is now focused on synchronization,
keeps interactive Docker credential prompts visible, and preserves the Git
details needed to diagnose publication failures. Containers can also use an
optional protected file or environment token fallback without placing secrets
in project configuration. GitHub and GitLab validation are aligned, and
production images are published from reviewed annotated release tags instead
of ordinary commits. Explicit CLI version overrides now accept supported stable
and lifecycle formats, including SemVer release candidates such as
v2.1.0-rc.1 and common PEP 440 forms such as 2.1.0rc1.

This is a backward-compatible Semantic Versioning minor release. Existing
explicit paths remain strict, while newly initialized projects use automatic
project and version discovery by default.

The release brings together the project-compatibility, editor, validation,
credential, CI/CD, and private-package improvements developed across the
untagged v2.1.0 checkpoints. The v2.1.0 commit and annotated tag are the stable
release point for that cumulative work; the notes below focus on supported
commands, installation, and upgrade behavior.

• Runtime detection for Python, Node.js, PHP, mixed, and generic repository layouts.
• Automatic source selection with a safe project-root fallback.
• Automatic version metadata discovery for Python __version__.py, pyproject.toml, and package.json.
• Mixed-project synchronization for supported Python and Node.js metadata.
• Python version-module updates preserve final newlines so standard end-of-file hooks do not rewrite generated metadata and reject release commits.
• Adaptive auto, custy, commitizen, and git commit-message validation providers.
• Optional Commitizen integration with a strict mode for projects that require it.
• Adaptive auto, native, and pre_commit Git-hook execution policies.
• Native behavior for projects without installed pre-commit hooks or with only
  an unused .pre-commit-config.yaml file.
• Safe direct execution for recognized Windows-generated pre-commit wrappers
  mounted into Linux containers, without silently bypassing custom hooks.
• Actionable Git-hook failures that preserve the hook's stdout, stderr, and exit status.
• Non-empty reviewed commit and tag messages are preserved; generated fallbacks
  are limited to missing or empty files and use the detected project name.
• Git-tag-only versioning for projects that intentionally have no supported version file.
• Explicit stable and lifecycle tag validation for SemVer-style and common
  PEP 440-style alpha, beta, release-candidate, development, post-release, and
  metadata-bearing values.
• Project-aware custy init that does not create Python files in non-Python repositories.
• Packaged changelog-template fallback for projects that have not run custy init yet.
• Project-owned changelog templates retain override priority, with clear errors for missing explicit custom templates.
• Automatic changelog repository-link discovery when the generated repository setting is left empty.
• Tag-message backups now honor the configured backup directory.
• Predictable main, backup, all-remote, and explicit CLI remote selection.
• Complete remote, synchronization, tag, and skip-tag propagation through supported pipelines.
• A focused three-step standalone push profile that validates the repository
  and remotes before synchronization without initializing a release workflow.
• Exclusive terminal ownership during Git push and workflow confirmation so
  credential and confirmation prompts remain visible.
• Disabled Rich rendering for hidden direct-command pipelines so standalone
  custy push retains the same stable prompts as custy run push.
• Direct terminal-stream passthrough when no managed token resolves, with clear
  PAT guidance before native Git asks for HTTPS credentials.
• Actionable push failures that preserve Git stdout, stderr, operation, exit
  status, remote, and tag context.
• Clear Docker credential-boundary guidance without storing or managing tokens
  in Custy configuration.
• Native-first GitHub and GitLab HTTPS token fallback for containers, sourced
  from protected external files or named environment variables.
• Guided custy configure credentials setup, secret-free status output,
  read-only access testing, and explicit provider removal.
• Opt-in Docker, Compose, and remote-image Make helpers with writable mounts
  limited to setup and read-only mounts for inspection and runtime use.
• Safe rejection of hidden PAT setup without docker run -it, avoiding the
  echoed-input fallback used by non-interactive password prompts.
• Per-push credential-helper injection without changing persistent Git config,
  plus non-interactive failure behavior that avoids indefinite prompts.
• Configurable Windows, Linux, macOS, and container editor priorities.
• Reliable Visual Studio Code launching on Windows installations that expose code.cmd.
• Micro, Nano, Vim, and Vi included in the production image for interactive release workflows.
• Clean terminal-editor buffers by suspending live pipeline progress until editing finishes.
• Expanded Make helpers and refreshed pre-commit hooks improve Python 3.14 contributor workflows.
• Clearer CLI errors with detailed tracebacks available through --debug.
• Successful no-command help behavior for local and container-based discovery.
• Verified Docker operation from a Docusaurus project without an app/ directory.
• GitHub and GitLab production image publication driven by annotated release
  tags with non-empty messages and matching normalized package versions, with
  latest reserved for stable releases and no separate commit-SHA image tag.
• Clean Python 3.14 CI state without tracked bytecode artifacts, plus portable
  CLI help assertions across GitHub and GitLab runners.
• Authorized installation of custy==2.1.0 from a private GitLab Python package
  registry.
• Updated English and Indonesian documentation for project detection, initialization, versioning, CLI errors, and Docker usage.

Changelog generation no longer depends on an editable template already existing
under .config/custy/. Before initialization, Custy safely uses the packaged
default. After initialization, the project's editable template remains the
preferred override.

If a project explicitly configures a custom template that does not exist, Custy
reports the invalid path instead of silently selecting another template. Tag
message backups also use the directory selected in project configuration.

When the changelog repository value is empty, Custy can derive a supported
repository URL from eligible Git remote metadata. An explicit configured URL
remains authoritative. If no usable repository URL can be resolved, changelog
generation can continue without links where the configured output permits it.

Custy now applies one consistent remote-resolution model across direct commands
and supported custy run pipelines:

• An explicit CLI remote has the highest priority for a focused operation.
• Configured push_to behavior selects main, backup, or all remote groups.
• All-remote execution combines configured main and backup remotes.
• Backup synchronization can extend a main-remote operation without replacing its primary destination.
• Selected remotes are validated before mutation.
• Dry-run performs the required discovery and validation but simulates local and remote changes.
• Standalone custy push and custy run push do not calculate a version,
  initialize release state, or wait for release confirmation.

The changelog repository URL and Git remote names serve different purposes.
The repository URL creates public changelog links, while default_remote,
main_remotes, and backup_remotes control Git operations and synchronization.

Custy continues to use normal Git credential helpers and SSH first. When an
HTTPS push runs inside a container that cannot inherit the host credential
manager, users may opt into a GitHub or GitLab token fallback:

• file reads a protected token file from /run/secrets/custy by default;
• environment reads the configured variable, such as
  CUSTY_GITHUB_TOKEN or CUSTY_GITLAB_TOKEN;
• container_only = true keeps local execution on native Git authentication;
• custy configure credentials provides guided setup without a visible token
  command-line option;
• status never displays token values and test uses read-only
  git ls-remote;
• SSH private keys remain outside Custy's ownership and must be supplied by the
  normal Git/SSH environment.

The fallback is injected only for the active Git command. Custy does not alter
system, global, or repository credential-helper configuration. Dry-run does not
read a token or contact the remote.

The Make interface keeps runtime credential mounting disabled by default. Use
CUSTY_CREDENTIALS_MOUNT=true only when a Docker, Compose, or remote-image run
should receive the external directory. Credential setup targets mount it
writable; status, access testing, and runtime targets mount it read-only. Token
values are never passed through Make variables.

Custy now resolves the editor used for commit and t...

Release v2.0.0

✅ Custy v2.0.0 — Stable Major Release

Custy v2.0.0 promotes the feature set reviewed in v2.0.0-rc.1 to the stable
2.0 release line. No new Custy command behavior was introduced after RC.1; the
final promotion combines repository cleanup with historical tag normalization
and recovery of missing GitHub Releases and container packages.

Custy 2.0 evolves the project from a mostly monolithic Git automation script
into a structured developer-productivity CLI with discoverable commands,
explicit release pipelines, centralized configuration, safer previews, and
clearer extension points.

🌟 Highlights

• Typer and Rich CLI with focused initialization, validation, versioning, changelog, commit, tag, push, backup, and cleanup commands.
• Reusable custy run dev, custy run release, and custy run full profiles with visible, deterministic step ordering.
• Namespaced .config/custy/config.toml configuration with CLI → configuration → default resolution.
• Rebuilt changelog generation with Conventional Commit parsing, configurable grouping and cleaning, pending content, release sorting, links, metadata, statistics, and Jinja templates.
• Determinate changelog progress for Unreleased content and every discovered Git tag.
• Consistent dry-run behavior that retains read-only discovery and validation while simulating intended file, editor, Git, and remote mutations.
• SemVer, PEP 440, Commitizen, date, and Git-count version strategies with separated Git execution and service boundaries.
• Multi-remote synchronization, structured message backups, retention cleanup, and protected branch-cleanup rules.
• Expanded CLI, core, integration, regression, configuration, logging, UI, workflow, dry-run, cleanup, and changelog test coverage.
• Docker, Docker Compose, modular Make targets, GitHub Actions, GitLab CI, pre-commit, packaging, and release automation.
• A dedicated bilingual Custy documentation hub through the Devalltect Docs portal.

🧹 Changes Since v2.0.0-rc.1

• Removed temporary development notes, scratch change lists, and completed version-specific TODO files.
• Archived the v2.0.0 development scope, decisions, completed work, future ideas, and release checklist in the tracking history.
• Performed final repository housekeeping for the stable release.
• Normalized historical Custy tags from PEP 440-oriented notation to Semantic Versioning notation.
• Recreated missing GitHub Releases for historical Custy 1.x versions from their corresponding tags.
• Rebuilt missing historical container images from their corresponding tags with Reflow and published them to GitHub Container Registry.

There are no additional supported-command behavior changes between
v2.0.0-rc.1 and v2.0.0.

📦 Repository and Distribution Recovery

The historical Custy repository distribution was normalized and restored as
part of the stable-release preparation:

• Historical version tags now follow the repository's Semantic Versioning convention.
• Historical prerelease identifiers use SemVer notation instead of the former PEP 440 notation.
• Missing GitHub Release pages for the Custy 1.x release line were reconstructed from their corresponding historical tags.
• Missing historical container images were rebuilt from the source associated with each tag using Reflow.
• Rebuilt images were published to GitHub Container Registry through GitHub Packages.
• Source tags, GitHub Releases, and container-image tags now use a more consistent versioning and distribution structure.

This recovery does not introduce source changes into those historical
versions. Publication timestamps for reconstructed GitHub Releases and
container images reflect the recovery operation and may differ from the
original software release dates.

Users and automation that reference former PEP 440-formatted Git tags,
release URLs, or container tags must update those references to their
corresponding SemVer names.

For example:

• Former tag: v1.4.0rc1
• SemVer tag: v1.4.0-rc.1

💻 For Custy Users

• Run custy init to create editable project configuration and templates.
• Run custy validate before consequential repository operations.
• Use individual commands for focused operations or a custy run profile for an ordered pipeline.
• Place global options before the command, such as custy --dry-run run release.
• Remember that dry-run can read real project and Git state and may write diagnostic logs, but intended project, Git, and remote mutations are simulated.

🧰 For Contributors and Integrators

• CLI presentation and core behavior are separated under app/cli and app/core.
• Git services, pipeline steps, version strategies, changelog processing, initialization, cleanup, UI, and configuration expose focused responsibilities.
• Smaller components and explicit protocols, services, factories, builders, presenters, and strategies make behavior easier to locate, test, replace, and extend.
• Modular development tooling and documented architecture simplify local validation and release maintenance.

📚 Documentation

The Devalltect Docs portal is the primary documentation experience for the
Custy 2.0 release line. It covers installation, commands, configuration,
pipelines, workflows, troubleshooting, user guidance, architecture, and
contributor workflows in both supported documentation languages:

• English (default): https://devalltect00.github.io/devalltect-docs/docs/custy
• Indonesian: https://devalltect00.github.io/devalltect-docs/id/docs/custy

Repository-local documentation may remain useful for project history and
source-level references, but users should follow the portal for current Custy
2.0 usage guidance.

⚠️ Upgrade Notes for 1.x Users

• Python 3.14 or newer is required.
• Replace .custor.toml with the generated .config/custy/config.toml configuration and review every generated value.
• Review editable resources under .config/custy/templates before running commit or release workflows.
• Replace custy all with custy run release or custy run full as appropriate.
• Replace custy commit-tag-bump with focused commands or a supported custy run profile.
• Replace custy cleaned-backups with custy cleanup backups.
• Replace custy clean-branches with custy cleanup branches.
• Use custy changelog generate for standalone changelog generation.
• Update Git, release, dependency, and container references that still use the former PEP 440 tag notation.
• Review custy --help and command-specific help before migrating automation.

⚠️ Experimental Feature

The custy workflow branch-policy command remains experimental. Its behavior
may change in later releases, so use it cautiously and preview intended
operations before allowing mutations.

✅ Release Status

• Version: v2.0.0
• Previous version: v2.0.0-rc.1
• Strategy: Semantic Versioning
• Stability: Stable for supported commands; custy workflow remains experimental
• Historical distribution: GitHub Releases and GHCR images restored
• Historical tag convention: Normalized to SemVer

Thank you for testing the release candidate and helping make Custy 2.0 ready
for its stable release line.

Release: v2.0.0
Author: Devalltect / Rizky Fernandes

---

📅 Release Information

• Version: 2.0.0
• Python Package Version: 2.0.0
• Release Type: release
• Project: devalltect00/Custy
• Commit: 9ff1d453

Release Candidate v2.0.0-rc.1

🚧 Custy v2.0.0-rc.1 — Major Architecture and Workflow Release Candidate

Custy v2.0.0-rc.1 is the first release candidate for the 2.0 major release.
It consolidates the large set of changes developed after the 1.10.x line and
is intended for users and contributors who want to validate the new CLI,
configuration system, changelog generator, and release pipelines before the
stable v2.0.0 release.

The central change in Custy 2.0 is a move from a mostly monolithic Git
automation script to a structured developer-productivity platform. Commands are
now easier to discover, workflows are explicit, configuration is centralized,
and the internal architecture is substantially easier to test, debug, maintain,
and extend.

🌟 Highlights

• A new Typer and Rich CLI with clearer help, output, progress, validation, and error guidance.
• Focused commands for initialization, validation, versioning, changelog generation, commit, tag, push, backup, and cleanup.
• Reusable custy run dev, custy run release, and custy run full pipelines with explicit ordered steps.
• A rebuilt, configuration-driven changelog system with Conventional Commit parsing, type/scope grouping, pending-commit support, release sorting, comparison links, and Jinja rendering.
• Determinate changelog progress that reports Unreleased content and every discovered Git tag during history collection.
• A centralized .config/custy/config.toml schema covering CLI behavior, paths, templates, versioning, Git remotes, cleanup, logging, workflows, and detailed changelog behavior.
• Improved SemVer, PEP 440, Commitizen, date, and Git-count version workflows.
• Safer Git operations, multi-remote synchronization, template backups, retention cleanup, and protected branch cleanup.
• Docker, Docker Compose, Make, GitHub Actions, GitLab CI, pre-commit, packaging, and release automation support.
• Comprehensive English and Indonesian documentation through the Devalltect documentation portal.

💻 Better for Custy users

• custy init creates the configuration and templates needed by a project.
• custy validate checks project readiness before release operations.
• Individual commands remain available when only one operation is needed.
• Pipeline profiles provide predictable end-to-end workflows without hiding execution order.
• Global --dry-run, --no-dry-run, --debug, and --log-level controls improve safety and troubleshooting.
• Dry-run keeps read-only discovery and validation available while simulating intended file, editor, Git, and remote mutations; normal diagnostic logging remains active.
• Rich terminal panels, tables, changelog progress output, and summaries make results easier to understand.

🧰 Better for contributors and integrators

• CLI presentation and domain behavior are now separated under app/cli and app/core.
• Git execution, version strategies, pipelines, changelog processing, initialization, cleanup, UI, and configuration have focused extension points.
• Smaller components and explicit interfaces make features easier to locate, test, replace, and extend.
• The test suite now covers CLI, core, integration, regression, configuration, logging, UI, and workflow behavior.
• Modular Make targets and documented architecture simplify local development and release maintenance.

📚 Documentation

Custy 2.0 introduces a dedicated documentation hub on the Devalltect Docs
portal. For current installation, command, configuration, workflow,
troubleshooting, user, and contributor guidance, use:

• English (default): https://devalltect00.github.io/devalltect-docs/docs/custy
• Indonesian: https://devalltect00.github.io/devalltect-docs/id/docs/custy

The portal is the primary documentation experience for the Custy 2.0 release
line. Repository-local documentation may remain useful for project history and
source-level references, but users should follow the portal for current usage
guidance.

📝 Changelog improvements

The changelog generator has been rebuilt around typed release and commit models.
It can clean and parse structured messages, recognize breaking changes, group
entries by type and scope, integrate a pending release commit, remove duplicate
entries, sort releases, generate comparison links, and render a consistent
CHANGELOG.md from configurable templates. A determinate progress display now
tracks Unreleased content and each discovered tag while history is collected.
During dry-run, the same collection and rendering can run without replacing the
existing changelog file.

⚠️ Upgrade notes for 1.x users

• Custy now requires Python 3.14 or newer.
• Replace .custor.toml with the generated .config/custy/config.toml configuration.
• Review generated files under .config/custy/templates before running commit or release workflows.
• Replace old custy all usage with custy run release or custy run full.
• Replace custy commit-tag-bump with focused commands or an appropriate custy run profile.
• Replace custy cleaned-backups with custy cleanup backups.
• Replace custy clean-branches with custy cleanup branches.
• Use custy changelog generate for standalone changelog generation.
• Run custy --help and each command's --help output before migrating automation scripts.

🧪 Recommended RC validation

Please validate this release candidate in a non-production repository first:

1. Install Custy v2.0.0-rc.1 in an isolated Python 3.14 environment.
2. Run custy init and review the generated configuration and templates.
3. Run custy validate.
4. Preview the intended profile with custy --dry-run run dev or custy --dry-run run release.
5. Verify version files, changelog output, commit/tag messages, remotes, cleanup rules, and configured diagnostic-log destinations before allowing side effects.
6. Report migration problems or unexpected output before the stable v2.0.0 promotion.

🚧 Release-candidate status

• This is a pre-release and is not yet the final production release.
• The custy workflow branch-policy feature remains experimental and should be used cautiously.
• Container publishing names and release metadata should receive a final verification before the stable release.
• The stable v2.0.0 release may include final cleanup, documentation corrections, migration refinements, and fixes discovered during RC validation.

Thank you for testing Custy 2.0 and helping validate the new foundation before
the stable release.

Release: v2.0.0-rc.1
Stability: Release Candidate
Author: Devalltect / Rizky Fernandes

---

📅 Release Information

• Version: 2.0.0-rc.1
• Python Package Version: 2.0.0rc1
• Release Type: rc
• Project: devalltect00/Custy
• Commit: 06b88d63

Custy v1.10.14 — Repository Recovery and Branch Alignment

🧠 Custy v1.10.14

Custy v1.10.14 is a maintenance release for the legacy Custy 1.x release line.

This release records repository recovery and branch-history alignment work completed after v1.10.13. It preserves the established Custy automation features while providing a synchronized and stable source baseline for the final 1.x version.

✨ Highlights

• Recorded the repository recovery and branch-alignment checkpoint.
• Restored consistency across the main, develop, and backup branch histories.
• Updated the application version from v1.10.13 to v1.10.14.
• Added the local temp.txt development file to .gitignore.
• Preserved the existing Custy command and configuration behavior.

🧰 Included Custy capabilities

The v1.10.14 source includes the established Custy 1.x functionality:

• Git commit and tag automation.
• SemVer and PEP 440 version strategies.
• Automatic project-version updates.
• Changelog generation from Git history.
• Commit-message and tag-message templates.
• Git workflow validation and enforcement.
• Main and backup remote synchronization.
• Dry-run and force controls.
• Commit-message and tag-message backups.
• Backup and temporary-branch cleanup commands.
• Local CLI and Make-based development workflows.

🔄 Changes since v1.10.13

🐛 Repository recovery

• Corrected repository-history consistency after recovery work.
• Recorded the aligned source state as the v1.10.14 release baseline.
• Preserved the intended relationship between primary and backup repository branches.

🔖 Version metadata

• Updated app/__version__.py from v1.10.13 to v1.10.14.

🔧 Repository maintenance

• Added temp.txt to .gitignore so local temporary content is not committed accidentally.

📦 Source-only availability

This historical release is published as source code only.

It does not include separately built or published:

• Python wheel or source-distribution artifacts.
• PyPI or GitLab Package Registry packages.
• GitHub Container Registry images.
• GitLab Container Registry images.
• Other prebuilt binaries or installation bundles.

GitHub and GitLab may provide automatically generated source archives for the tag.

🧪 Install from the Git tag

Install directly from the existing source tag:

python -m pip install "git+https://github.com/devalltect00/Custy.git@v1.10.14"

Or clone the tagged source:

git clone --branch v1.10.14 --depth 1 https://github.com/devalltect00/Custy.git
cd Custy
python -m pip install .

Verify the installation:

custy --help

🐍 Compatibility

• Required Python version: Python 3.11 or newer.
• The legacy project documentation recommends Python 3.11 or 3.12 for its pinned dependency set.

⚠️ Legacy release notice

Custy v1.10.14 belongs to the legacy 1.x architecture and command interface. It predates the redesigned Custy 2.x application, configuration system, pipelines, documentation, and safety improvements.

When using this version, consult the README and documentation stored in the v1.10.14 source tag because current Custy 2.x documentation may describe different commands and behavior.

📌 Release metadata

• Version: v1.10.14
• Previous version: 1.10.13
• Release type: Maintenance release
• Release date: April 1, 2026
• Source commit: f2d12bdbdd56d169ce733c29bae464efd8422e06
• Distribution: Source only
• Stability: Final legacy release

---

Full Changelog: v1.10.13...v1.10.14

---

Released by Devalltect / Rizky Fernandes