Update well inventory CSV feature header expectations

[marissafichera]

Summary
Updates the well inventory CSV CLI feature spec to reflect the current bulk upload requirements and expected validation behavior.

What Changed
Replaced the existing well-inventory-csv.feature content with the updated end-to-end Gherkin spec
Expanded happy path coverage for:
required and optional well inventory fields
optional water level entry fields
datetime parsing and Mountain Time handling
reordered columns
extra unknown columns
quoted comma-containing values
auto-generated well_name_point_id values
Added negative validation coverage for:
contact, address, phone, email, and postal code validation
required field enforcement
invalid lexicon, date, numeric, and boolean values
duplicate well_name_point_id values
invalid UTM coordinates
water level field dependency rules
empty files, header-only files, unsupported file types, row limits, repeated headers, duplicate headers, and unsupported delimiters
Why
This brings the feature file in line with the intended CLI bulk-upload behavior and gives the test/spec layer broader coverage for both acceptance and validation scenarios.

Testing
Verified the updated Gherkin content in well-inventory-csv.feature
No code execution required for this spec-only change

[Copilot]

Pull request overview

Updates the Behave/Gherkin spec for the CLI well-inventory CSV bulk upload to match current header expectations and validation behavior.

Changes:

• Removed the @production tag from the feature.
• Removed monitoring_status from the optional well-inventory field list.

Comments suppressed due to low confidence (1)

tests/features/well-inventory-csv.feature:130

• The optional field list contains a duplicate entry for "well_measuring_notes". Duplicates make the spec harder to maintain and can hide accidental omissions in the header expectation list; please remove the repeated row so each field appears only once.

      | well_notes                        |
      | well_measuring_notes              |
      | water_notes                       |
      | well_measuring_notes              |
      | sample_possible                   |

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b70b036e8b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore @production tag on this feature

I checked the Run BDD tests step in .github/workflows/tests.yml (line 189), which runs behave with --tags="@backend and @production and not @skip"; removing the file-level @production tag here means every scenario in this feature is now excluded from that CI suite. This silently drops coverage for the well-inventory CSV flow and can allow regressions in production-gated behavior to merge undetected unless @production is added back (file-level or scenario-level).

Useful? React with 👍 / 👎.

[ksmuczynski]

I think monitoring_status should be kept. Can you explain the reasoning for removing it?

[jirhiker]

The users do not want a separate field for monitoring_status. They want to combine the monitoring frequency and monitoring status in the same way as on the well inventory form. The backend will just need to parse the monitoring_frequency column and save data to the appropriate database fields. The csv does not need to be a 1:1 reflection of the database

[ksmuczynski]

@marissafichera @jirhiker My recent PR #596 also contains a few updates to tests/features/well-inventory-csv.feature. Might I suggest reviewing my PR before merging this? I've set my PR as draft since I plan to review Codex comments tomorrow.

[ksmuczynski]

Kept monitoring_status field in source csv for clarity, but normalized "Complete" monitoring_frequency values so that when monitoring_frequency = Complete, monitoring_frequency is cleared/set to None and monitoring_status is set to Not currently monitored (see commit f482b5a in PR #596 )

If needed, I can open a separate PR in the future adding a field to the source csv that allows for additional context/reason for a "Complete" monitoring frequency (eg. Physical obstruction, visited for inventory purposes only, etc.)