The PR #5 merge landed with the title "x" — a leftover from a dry-run merge check I made while resolving the conflicts. The content is correct; this fixes only the commit message.
No code changes: the diff against master is empty apart from the message.
The PR #5 merge landed with the title "x" — a leftover from a dry-run merge check I made while resolving the conflicts. The content is correct; this fixes only the commit message.
No code changes: the diff against `master` is empty apart from the message.
Adds the pages that were missing: an "Active Beers" view of what is in the
fermenter right now, and the per-run metadata (canonical name, tap number,
original gravity, brew notes) that could not be derived from the readings.
Why the metadata is needed
--------------------------
The `beer_data` collection stores a beer name on *each reading*, and that
name drifts within a run - run 4 was entered as "Necatron-Christmas Beer",
then "Nocturna the Christmas beer", then "Nocturna Christmas beer". There was
nowhere to record a tap number, a confirmed original gravity, or a note about
the brew.
The new `beer_runs` collection holds one document per run with exactly those
details. It starts empty; `scripts/backfill_run_metadata.py` populates it
from the existing readings. The script is idempotent, only ever inserts into
`beer_runs`, never touches `beer_data`, and never overwrites a name you have
already set by hand.
The active beers page
---------------------
A card per brew that is still in the fermenter, showing the tap number, the
current gravity, the projected alcohol, how many days it has been brewing, a
sparkline of the gravity so far, and the latest comment.
A run with only one reading and no recorded original gravity has no reliable
estimate, so the alcohol figure shows a dash rather than a misleading number
- record the OG or take a second reading and it appears. The same applies to
the existing reads, where the legacy app's assumed OG of 1012 produced
*negative* alcohol for a perfectly normal OG.
Also adds the history page: alcohol by brew, brews per month, every run in a
table, a comparison of the standard ABV formula against the legacy one, and
a list of readings that fall outside the plausible hydrometer range.
Changes to the existing pages
-----------------------------
- The brew-process page and the run detail page now show the canonical run
name and the latest comment, and the run detail page lets you edit the
metadata inline.
- Gravity is displayed as a decimal reading (1.039) with the point scale
beneath it (39 points), which is the way a brewer reads it. Labelling the
stored `1039` as "1039 points" would have been wrong.
- A run's display name now prefers the name on its *final* reading - the one
written when the brew was finished, so the name the operator settled on -
falling back to the most-used name.
- `upsert_run_metadata` now clears a field when it is passed as `None`, so a
name or tap number can be deleted. `upsert_run_metadata_partial` is the
non-clearing variant, used by the backfill.
Bugs found and fixed along the way
----------------------------------
- The chart script was included both in the base template and again by each
page, so every chart was drawn twice. A test now asserts it is loaded
exactly once per page.
- The chart library was never referenced by the base template, so all charts
were silently dead. That was fixed in the previous PR.
- An unfinished run reported a *measured* ABV. `abv_percent()` now returns
None for a run that is still in the fermenter - its figure is a projection,
not a measurement. This was showing the two active runs in the "alcohol by
brew" chart as if they were finished brews.
- The `/api/runs` endpoints the charts fetch from did not exist, so every
chart was silently empty. They are back, with tests.
- The "brews over time" chart left out the months with no brews, which
spaced the busy months evenly and made the chart read as continuous
activity. The quiet months are now included with a zero.
Tests
-----
105 (up from 74). New coverage: the active page contents, the tap number,
the projected alcohol, the "needs 2nd reading" case, metadata saving and
clearing, the stored name overriding the drifting reading name, the next
free tap number, the partial-update semantics, the history page, the
outlier list, and the point-scale formatting.
Data safety
-----------
`beer_data` is untouched by this change. The backfill script only inserts
into `beer_runs` and skips any run whose name has already been set by hand.
This Pull Request (PR) is purely administrative in nature. Its sole objective is to correct a placeholder commit message ("x") from a previous merge conflict resolution to a descriptive and professional one.
After a comprehensive cross-domain review encompassing Code, Security, and Infrastructure, it has been verified that there are no changes to the functional codebase, configuration files, dependencies, or infrastructure manifests. The PR modifies only the Git metadata. Because there is no logic change, the risk profile is negligible. All three review domains have returned an "Approved" or "Secure" status.
2. Prioritized List of Issues
There are no functional bugs, security vulnerabilities, or infrastructure misconfigurations.
Priority
Issue
Domain
Description
Low
Git History Flux
Code/Infra
Rewriting history on shared branches can cause synchronization issues for other contributors (force-pushing).
3. Domain-Specific Recommendations
💻 Code Quality & Workflow
Verification: Developers should double-check commit messages during the git merge or git commit prompt to avoid the need for subsequent history rewrites.
Automation: Implement a commit-msg git hook to prevent generic or single-character commit messages (e.g., "x", "fix", "update") from being committed.
🛡️ Security Posture
Commit Hygiene: While this PR is safe, the team is reminded to ensure that commit messages—especially during hurried conflict resolutions—do not inadvertently contain sensitive data such as API keys, internal IPs, or credentials.
⚙️ Infrastructure & Version Control
Merge Workflow: For complex conflict resolutions, it is recommended to use git merge --no-commit. This allows the developer to verify the final state of the code and craft a meaningful commit message before finalizing the merge, reducing the need for "fixup" PRs.
4. Positive Aspects of the PR
Professionalism: The initiative to clean up the project history demonstrates a commitment to maintainability and professional auditing standards.
Low Risk: The change is surgically limited to metadata, ensuring zero regression in application stability or security.
Clarity: The PR description clearly explains the "why" behind the change, making the review process straightforward.
5. Overall Assessment & Recommendation
Final Rating: ✅ Approved
Justification:
The PR achieves its goal of improving the project's audit trail without introducing any technical risk. There are no functional changes to the application, no new security attack vectors, and no infrastructure regressions. The minor concerns regarding Git history are outweighed by the benefit of a clean and descriptive commit log.
Action: Merge the PR and coordinate with the team if a force-push is required for a protected branch.
## PR Review Results
# Synthesized Review Report: docs: fix the PR #5 merge commit message
## 1. Executive Summary
This Pull Request (PR) is purely administrative in nature. Its sole objective is to correct a placeholder commit message ("x") from a previous merge conflict resolution to a descriptive and professional one.
After a comprehensive cross-domain review encompassing **Code**, **Security**, and **Infrastructure**, it has been verified that there are **no changes to the functional codebase, configuration files, dependencies, or infrastructure manifests**. The PR modifies only the Git metadata. Because there is no logic change, the risk profile is negligible. All three review domains have returned an "Approved" or "Secure" status.
---
## 2. Prioritized List of Issues
There are no functional bugs, security vulnerabilities, or infrastructure misconfigurations.
| Priority | Issue | Domain | Description |
| :--- | :--- | :--- | :--- |
| **Low** | Git History Flux | Code/Infra | Rewriting history on shared branches can cause synchronization issues for other contributors (force-pushing). |
---
## 3. Domain-Specific Recommendations
### 💻 Code Quality & Workflow
* **Verification:** Developers should double-check commit messages during the `git merge` or `git commit` prompt to avoid the need for subsequent history rewrites.
* **Automation:** Implement a `commit-msg` git hook to prevent generic or single-character commit messages (e.g., "x", "fix", "update") from being committed.
### 🛡️ Security Posture
* **Commit Hygiene:** While this PR is safe, the team is reminded to ensure that commit messages—especially during hurried conflict resolutions—do not inadvertently contain sensitive data such as API keys, internal IPs, or credentials.
### ⚙️ Infrastructure & Version Control
* **Merge Workflow:** For complex conflict resolutions, it is recommended to use `git merge --no-commit`. This allows the developer to verify the final state of the code and craft a meaningful commit message before finalizing the merge, reducing the need for "fixup" PRs.
---
## 4. Positive Aspects of the PR
* **Professionalism:** The initiative to clean up the project history demonstrates a commitment to maintainability and professional auditing standards.
* **Low Risk:** The change is surgically limited to metadata, ensuring zero regression in application stability or security.
* **Clarity:** The PR description clearly explains the "why" behind the change, making the review process straightforward.
---
## 5. Overall Assessment & Recommendation
**Final Rating: ✅ Approved**
**Justification:**
The PR achieves its goal of improving the project's audit trail without introducing any technical risk. There are no functional changes to the application, no new security attack vectors, and no infrastructure regressions. The minor concerns regarding Git history are outweighed by the benefit of a clean and descriptive commit log.
**Action:** Merge the PR and coordinate with the team if a force-push is required for a protected branch.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The PR #5 merge landed with the title "x" — a leftover from a dry-run merge check I made while resolving the conflicts. The content is correct; this fixes only the commit message.
No code changes: the diff against
masteris empty apart from the message.PR received — starting review, sit tight 🫡
PR Review Results
Synthesized Review Report: docs: fix the PR #5 merge commit message
1. Executive Summary
This Pull Request (PR) is purely administrative in nature. Its sole objective is to correct a placeholder commit message ("x") from a previous merge conflict resolution to a descriptive and professional one.
After a comprehensive cross-domain review encompassing Code, Security, and Infrastructure, it has been verified that there are no changes to the functional codebase, configuration files, dependencies, or infrastructure manifests. The PR modifies only the Git metadata. Because there is no logic change, the risk profile is negligible. All three review domains have returned an "Approved" or "Secure" status.
2. Prioritized List of Issues
There are no functional bugs, security vulnerabilities, or infrastructure misconfigurations.
3. Domain-Specific Recommendations
💻 Code Quality & Workflow
git mergeorgit commitprompt to avoid the need for subsequent history rewrites.commit-msggit hook to prevent generic or single-character commit messages (e.g., "x", "fix", "update") from being committed.🛡️ Security Posture
⚙️ Infrastructure & Version Control
git merge --no-commit. This allows the developer to verify the final state of the code and craft a meaningful commit message before finalizing the merge, reducing the need for "fixup" PRs.4. Positive Aspects of the PR
5. Overall Assessment & Recommendation
Final Rating: ✅ Approved
Justification:
The PR achieves its goal of improving the project's audit trail without introducing any technical risk. There are no functional changes to the application, no new security attack vectors, and no infrastructure regressions. The minor concerns regarding Git history are outweighed by the benefit of a clean and descriptive commit log.
Action: Merge the PR and coordinate with the team if a force-push is required for a protected branch.