PlantForge

Summary

The Raspberry Pi 5 now boots from its 64GB microSD card, joins the local network, and passes its power and thermal checks. The soil sensor appears at I2C address 0x36, the BME280 appears at 0x77, and the restricted hardware process returns raw readings from both devices.

Physical Evidence

• Power health reports throttled=0x0 after correcting the power connection.
• The case fan is connected correctly and governed by the Pi cooling interface.
• The first bounded read returned soil capacitance 364, temperature 25.50 C, relative humidity 57.27%, and pressure 1021.40 hPa.
• Five dry screening readings held between 334 and 338. The recorded dry references are 337, 335, and 335, with a median of 335.
• The first wet-reference set had a median of 886 and a range of 24. PlantOS rejected it because the permitted range is 12.
• A later screening window ranged from 850 to 922, so no replacement wet reference was recorded.
• The PlantOS authority envelope remains recommendation-only with canActuate: false and human confirmation required.

Software State

• The Pi now runs PlantOS 0.2.0-rc.2.
• The quality gate reads the authoritative installed state from /var/lib/plantos.
• All 99 PlantOS tests pass and type checking is clean.
• Every calibration path rejects unstable dry or wet references above the same bounded range.

Commissioning Boundary

• A successful raw read proves connectivity, not calibration or care accuracy.
• The soil reading must not influence a watering recommendation until dry and wet reference sessions pass.
• The API and collector remain disabled during calibration.
• No automatic watering hardware or actuation route is present.

Next Steps

• Inspect and secure the probe position, insertion depth, substrate contact, and cable strain.
• Screen the settled position again without moving the probe between readings.
• Replace the rejected wet-reference samples only after the screening range is 12 or less.
• Validate calibrated observations against a manual soil inspection before beginning the 24-hour study.

Summary

The Raspberry Pi 5, heatsink, official case fan, power supply, environmental sensor, soil sensor, connection cables, and blank 64GB microSD card have been received and inspected. The Pi is assembled, the fan is connected, and the storage card awaits imaging through the ordered USB reader.

Commissioning Boundary

• Hardware possession is not physical proof.
• The API remains disabled until preflight, installation, and verification pass.
• Sensors remain disconnected until the Pi is powered down and ready for the first bounded I2C session.
• Fan operation and thermal response still require verification after boot.

Software Verification

• A fail-closed Raspberry Pi preflight, bootstrap, service unit, and installation verifier are complete.
• All 95 PlantOS tests, type-checking, linting, Bash syntax, and Linux validation pass.
• The installer refuses unsupported operating systems, non-loopback hosts, missing runtime files, simulated evidence, and incomplete installations.
• Software review does not claim that physical hardware has passed.

Next Steps

• Image Raspberry Pi OS on the blank microSD card.
• Complete the first boot, network setup, updates, and SSH access.
• Run preflight, bootstrap, and installation verification before enabling the API.
• Power down, connect the sensors, scan I2C, and capture the first physical observations.

Summary

A second-model review found no actuation risk and identified two commissioning blockers plus four operational defects. The reviewed release candidate closes all six before hardware arrives.

Corrections

• Collector slots now keep stable identifiers across power loss.
• Simulation data cannot enter physical stores or pass physical gates.
• Evidence export requires every commissioning artifact.
• Physical acceptance rechecks mode, files, safe paths, and hashes.
• Pi services resolve npm safely and stop repeated failure loops.

Verification

• All 87 automated tests pass.
• Linux validation rejects incorrect line endings instead of repairing them.
• An accelerated simulated flow leaves physical paths empty and remains blocked.
• The recommendation-only boundary remains unchanged.

Independent Sign-Off

The reviewer re-checked the release candidate against the reported fixes and confirmed all six findings closed. Both commissioning blockers were reproduced and retested by execution: the restart path no longer duplicates a reading, and a simulated bundle is refused as physical evidence. The read-only, recommendation-only, and human-confirmation boundaries hold. This sign-off covers the software review only. It is not proof that physical hardware has passed.

Release Boundary

The final v0.2.0 release still requires accepted physical calibration, a healthy 24-hour physical window, and a verified physical evidence bundle.

Summary

PlantOS is packaged for arrival day with a Linux-validated service boundary, a single guided gate check, a visible completion checklist, and a reviewable sample evidence bundle.

Verification

• The Pi bootstrap passes Bash syntax validation inside a Linux container.
• Both systemd units retain restricted write paths and non-root application authority.
• The guided arrival check reports inventory, I2C, calibration, collection, and evidence gates in sequence.
• The sample ZIP is explicitly marked simulated and cannot be mistaken for physical proof.

Release Boundary

• Software readiness is frozen at v0.2.0-rc.1.
• Automatic watering remains outside the system boundary.
• The final v0.2.0 release remains blocked on physical calibration and a healthy 24-hour observation window.

Next Steps

• Inventory the delivered parts.
• Flash and boot the Raspberry Pi.
• Run the guided arrival check after each gate.
• Replace simulated evidence with the first physical evidence bundle.

Summary

The arrival-day workflow now has an operational layer around the existing calibration and observation contracts.

System Work

• Added atomic collector checkpoints and systemd restart recovery.
• Added a read-only commissioning API status route.
• Added a commissioning view to the touch interface preview.
• Added a ZIP evidence exporter with SHA-256 file hashes.

Safety

• The API remains GET-only.
• The interface displays actuation as disabled.
• The evidence bundle excludes credentials.
• Physical proof remains pending until the ordered hardware arrives.

Next Steps

• Install the Pi service files.
• Complete dry and wet calibration.
• Run the 24-hour physical collection.
• Export and preserve the first physical evidence bundle.

Summary

The physical commissioning workflow can now be exercised before delivery using simulated I2C sensors and an accelerated 24-hour observation window.

System Work

• Added an arrival-day runbook with explicit stop gates and recovery paths.
• Added simulated dry, wet, and normal sensor states behind the physical transport interface.
• Added a persistent collector and health report for completeness, gaps, and freshness.
• Added calibration stability and reference-span reporting.

Acceptance

• All 83 automated PlantOS tests pass.
• 289 readings represent a complete five-minute, 24-hour window.
• Observation completeness must be at least 95 percent.
• No observation gap or latest-reading age may exceed ten minutes.
• Calibration references must remain within a 12-unit range.

Next Steps

• Run the rehearsal before unboxing.
• Replace simulated readings with physical evidence without changing interfaces.
• Preserve all commissioning artifacts as the first node evidence bundle.
• Keep actuation outside the system boundary.

Summary

The initial Raspberry Pi hub, environmental sensor, capacitive soil sensor, case, power supply, connection cables, and boot storage have been ordered. The main Adafruit shipment is expected August 4.

Decisions and Lessons

• Keep the Raspberry Pi in the consolidated Adafruit order because splitting the purchase saved only $10 after shipping.
• Use the official 64GB A2/V30 microSD card as the first boot and recovery medium.
• Start with a fully digital I2C sensor chain and no analog converter.
• Record delivered cost separately from component-list prices.

Investment

• Adafruit hardware order: $269.17.
• PiShop.us microSD order: $39.46 including shipping and tax.
• Total initial hardware investment: $308.63.

Next Steps

• Image Raspberry Pi OS and run the prepared bootstrap script.
• Inventory every component on arrival.
• Assemble the dry bench system before placing a sensor in substrate.
• Begin the bounded dry and wet calibration session only after raw I2C readings are stable.

Summary

PlantOS now persists validated observations, guides dry and wet moisture calibration, and accepts hardware-shaped input from BME280 and Adafruit STEMMA soil adapters. A read-only Linux I2C bridge and commissioning CLI are ready before delivery. Sensor access remains behind an injected transport, so it cannot bypass deterministic policy.

Decisions and Lessons

• Use the same observation contract for simulation and hardware.
• Require an explicit calibration span before normalizing moisture.
• Keep raw history out of the conversational tool schema.
• Preserve the read-only authority boundary during commissioning.
• Keep the 35-of-38 qwen3.5 candidate unpromoted until every raw-model gate passes.

Verification

• Type checking, linting, formatting, and all 77 automated tests pass.
• All eight policy outcomes remain unchanged with physical-provider-shaped observations.
• The local observation store validates records on append and read.
• The calibration workflow rejects incomplete sampling and weak reference spans.
• The release record distinguishes software readiness from physical proof.

Next Steps

• Run the I2C scan and raw-read checks after the hardware arrives.
• Capture real dry and wet reference medians.
• Record 24 hours of physical observations and verify restart persistence.
• Create the v0.2.0 tag only after commissioning passes.

Summary

PlantOS now models calibration, provenance, missing context, next signals, and action authorization as strict TypeScript contracts. Eight deterministic scenarios flow through a read-only OpenAPI service. Open WebUI is offered only the guarded care-explanation route, which renders a fixed five-part decision envelope before model language can affect the response.

Decisions and Lessons

• Make unsafe authorization states invalid at the contract boundary.
• Keep deterministic PlantOS policy authoritative over model language.
• Let Ollama explain validated facts, never determine care state or authority.
• Reject changed numbers, action language, questions, and overlong model output.
• Fall back silently to deterministic language when the model is offline or rejected.

Verification

• PlantOS type checking is clean and the guarded software baseline passes its automated suite.
• The live eight-scenario guarded-renderer gate passes, including exact stale, visual-conflict, and recent-watering checks.
• Six authenticated Open WebUI acceptance scenarios preserve canActuate: false.
• The stable plantforge:v0.1.11 profile remains the default.
• The qwen3.5:9b candidate remains unpromoted after scoring 35 of 38 raw-model cases.

Next Steps

• Commission the first physical node without changing the software contracts.
• Compare real observations with all eight deterministic scenarios.
• Capture calibration references and validate provenance against physical readings.
• Continue refining the three remaining local-model evaluation failures before promotion.

Summary

PlantOS now includes a Figma-ready touch UI specification, weather and calibration-aware simulation, validated plant-profile and care-history contracts, a dashboard history surface, and a five-state evaluation harness. The work is intentionally useful before a sensor is purchased.

Decisions and Lessons

• Hardware should enter a defined system, not define it.
• Human care history and overrides are first-class product evidence.
• Calibration is a commissioning process, not a one-time threshold.
• Every safety state needs a visible experience and an automated check.

Next Steps

• Build PlantOS Touch UI v0.1 in Figma from the shared specification.
• Choose the first plant and complete its profile before installation.
• Commission the first node against the calibration plan.
• Compare real observations with the simulation baseline.

Summary

PlantOS now has strict TypeScript contracts, deterministic baseline and fault scenarios, an explainable safety-first policy, append-only local decision trails, and a local read-only API. The Living Whitepaper display emulator loads the generated fixture and shows the evidence path that produced each recommendation.

Decisions and Lessons

• Keep the Python simulator as a research baseline.
• Use TypeScript for shared contracts and new application code.
• Model healthy, watering-review, stale, missing-data, and conflicting-signal states before dashboard implementation.
• Never permit degraded evidence to become a watering recommendation.
• Record the evidence path in append-only order before exposing the recommendation.

Next Steps

• Build a dedicated research dashboard from the same API.
• Add accessibility evidence and narrow-view testing.
• Compare fixture behavior with the first physical sensor node.
• Prepare the v0.2.0 release record.

Summary

PlantOS gained a simulation-first code scaffold. The FI Cycle was applied to define the correct result, determinants, guardrails, leading indicators, and expected friction relocation.

Decisions and Lessons

• Develop the software before hardware arrives.
• Recommend before actuating.
• Treat overrides and notification burden as evidence.
• Keep relocated maintenance work visible.

Next Steps

• Define a persistent observation store.
• Add sensor-health states.
• Record simulated recommendation outcomes in the Friction Ledger.

Summary

PlantForge officially started. The vision, product philosophy, architecture direction, and Living Whitepaper structure were established.

Decisions and Lessons

• Use Friction Inversion as the core philosophy.
• Begin with Raspberry Pi.
• The project is about cognitive load, not soil moisture.

Next Steps

• Research premium moisture sensors.
• Prototype the first hardware stack.
• Define the initial data model.