Fix SymphonyElixir.Version coverage gate

[BetterAndBetterII]

Context

Coverage CI is blocked because SymphonyElixir.Version only hit the charlist :vsn path in tests while the repository still enforces a strict 100% threshold. This PR ships the reviewed spec plus the implementation that restores the existing gate without weakening CI.

Refs #19.

TL;DR

Normalize raw app version metadata in one place and add focused tests so coverage returns to 100%.

Summary

• route SymphonyElixir.Version.current/0 through a single normalize/1 parsing boundary
• add focused tests for binary, charlist, fallback, and runtime smoke coverage in version_test.exs
• keep the reviewed Issue 19 remediation plan in SPEC.md and document the gh scope fallback in AGENTS.md

Alternatives

• lower the coverage threshold; rejected because the issue is specifically to restore the existing CI gate
• mutate global application metadata in tests; rejected because a pure normalization boundary is simpler and safer
• add dead production branches just to satisfy coverage; rejected because the implementation should match the real runtime parse boundary

Test Plan

• make -C elixir all
• cd elixir && mix test test/symphony_elixir/version_test.exs
• make -C elixir coverage
• cd elixir && mix specs.check

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a comprehensive remediation plan to resolve a critical CI blockage caused by insufficient code coverage in the SymphonyElixir.Version module. The plan outlines the scope, technical requirements, implementation milestones, and testing strategy to restore 100% coverage without compromising existing quality gates or introducing unnecessary production code.

Highlights

• Coverage Remediation Plan Documented: A detailed plan for addressing Issue 19, which concerns the SymphonyElixir.Version module's incomplete code coverage, has been added to SPEC.md.
• Root Cause Identified: The root cause of the coverage failure, specifically that only the charlist :vsn path is covered in the current test runtime, is documented.
• Implementation Test Plan Defined: A comprehensive test plan is outlined to ensure make -C elixir all passes without weakening CI, including steps to verify specific metadata shapes and confirm 100% coverage.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• SPEC.md
  • Added a new section detailing the Issue 19 coverage remediation plan.

Activity

• This is a draft pull request that carries a reviewed remediation plan for the SymphonyElixir.Version module's code coverage issue.
• The PR description includes a test plan with mix specs.check and make -C elixir coverage already marked as completed, indicating initial verification of the specification itself.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds a detailed and well-structured remediation plan to SPEC.md for fixing the code coverage of the SymphonyElixir.Version module. The plan correctly identifies the root cause, defines a clear scope, outlines affected boundaries, and provides concrete milestones and a test plan. The risk assessment is also thorough. My feedback includes one suggestion to improve the clarity of the test plan section.

_{Note: Security Review has been skipped due to the limited scope of the PR.}

[gemini-code-assist]

The first step in this test plan, Run cd elixir && mix specs.check after updating this specification, creates some ambiguity. It seems to refer to validating the current spec update, while the other steps clearly refer to validating the future code implementation. To improve clarity, this test plan should focus solely on steps to be performed after the implementation. Consider moving the spec-checking step to the PR description for this change, or rephrasing it to be run 'after implementation' if it is also relevant then.

[BetterAndBetterII]

Updated SPEC.md section 21.4 to split spec-review validation from post-implementation validation. mix specs.check now sits under an explicit spec-review step, and the remaining commands are all marked as post-implementation checks.

[BetterAndBetterII]

[codex] Changes since last review:

• implemented the approved Issue 19 fix by routing SymphonyElixir.Version.current/0 through normalize/1
• added focused coverage for binary, charlist, fallback, and runtime smoke paths in version_test.exs
• refreshed the PR title/body to reflect the full branch scope (spec + implementation + env note)
  Commits: d8c446f
  Tests: cd elixir && mix test test/symphony_elixir/version_test.exs, make -C elixir coverage, make -C elixir all