Coding, Programming & Scripting
A forestry company's legacy weekly-report scripts, modernised into one tested, installable package.
Fictionalised summary. Company names, the contact email and repository addresses are placeholders; no credential or token values are shown.
Domain & SKU
What this example orders, at a glance.
- Domain
- Coding, Programming & Scripting
- Deliverable
- Codebase Modernization Task
- Turnaround
- Standard (48 hours)
- Environments in scope
- Linux VM
- Compliance
- None apply
02
Current State
Baseline architecture, stack, repository context and known friction.
Architecture & system context
Three legacy scripts run our weekly stand-report every Monday in sequence: fetch_plots.py pulls plot data, build_report.py builds a CSV, and mail_out.py emails the result. They were written by a former analyst in an old style, with global state, hardcoded paths and a single giant main block, and they are not tested.
Tech stack, frameworks & versions
- Python 3.11 (old-style code)
- Sample CSV input files
- smtplib email step
- No test framework
Known issues, error logs & friction
The scripts are untestable and undocumented. Paths and recipients are hardcoded, errors are silently ignored, and the only tribal knowledge is 'run them in order every Monday, and if the map is off, re-run fetch twice'.
Primary repository or architecture link
https://github.com/your-org/your-repoCodebase shape, languages & test coverage
Three scripts of roughly 80, 70 and 40 lines, plus two small sample-data files. No package structure, no tests, hardcoded paths and recipients, and no configuration file.
03
Target State
Deliverable expectations, measurable benchmarks and definition of done.
Deliverable expectations
One installable Python package with a single CLI entry point named redwood-stand-report that produces the same outputs on the sample data, replaces hardcoded paths and recipients with configuration and environment values, and ships with tests and a migration guide.
Quantifiable benchmarks & success metrics
Unit tests cover at least 80% of the new modules; the same sample outputs are produced; zero hardcoded paths or recipients remain.
Definition of done
The package installs, the CLI reproduces the sample outputs, the tests pass, configuration replaces hardcoded values, and MIGRATION.md maps the old commands to the new ones.
Non-regression & test requirements
The report outputs must be equivalent on the sample data, and the parse, build and send logic must each have unit tests. The weekly operator must be able to run the same Monday job through one command.
Modernization targets
- Package the three scripts into one installable package
- Add a single CLI entry point
- Replace hardcoded paths and recipients with configuration
- Add unit tests and a migration guide
04
Constraints
Forbidden changes, compliance, regions, freeze windows and deadlines.
Forbidden modifications & boundaries
Do not change the report's output format or content; do not send live email during testing, and do not touch the production scheduler.
Compliance standards
- None apply
Approved regions & environments
- Linux VM in the us-west region
Freeze windows & blackout periods
No production changes Fri 17:00 to Mon 06:00 Pacific.
Pinned libraries, versions & standards
Stay on Python 3.11; prefer the standard library and avoid new runtime dependencies.
Target deadline or milestone
24 October, before the quarterly timber inventory report.
Approved languages, frameworks & linters
Python 3.11, standard library first; no new runtime dependencies without review.
05
Access & Verification
Repository access, read-only credentials, environments and verification.
Handover method
Repository access
Git repository URL
https://github.com/your-org/your-repoRead-only repository token
Encrypted in your browser before it leaves the device.
Environments in scope
- Linux VM
Build, test & run commands
python -m pytest for tests; run the CLI with python -m redwood_stand_report.
Contact email
Acceptance criteria as captured
These are the testable statements fixed before payment. Delivery is checked against this list.
- The three scripts become one installable Python package with a single CLI entry point (`redwood-stand-report`) and the same outputs on the sample data.
- Unit tests cover the parse, build and send logic (at least 80% of the new modules).
- No hardcoded paths or recipients remain: configuration file plus environment.
- A `MIGRATION.md` maps the old commands to the new commands for the Monday operator.
From the live intake
Captured screenshots of this work order being filled in. Each image is scrollable — scroll inside a frame to see the full page.
What happens after payment
Payment confirms the fixed scope. From there the work runs to the SLA you selected and every step is visible on your private dashboard.
The SLA clock starts
Your turnaround countdown begins the moment payment is confirmed — under 14 hours overnight, or 48 hours standard. Early delivery is always the goal.
A private dashboard
Your tracking link opens a private work-order dashboard showing the five delivery stages and every update as the work progresses.
Verified delivery
The deliverable is returned as a verified pull request or documented package, checked against the acceptance criteria you agreed before payment.
Your downloads
The final report, the acceptance-criteria results and every file in the delivery package are available on the dashboard until you close it.