Ongoing Features/Work

[ANTFOR7717]

Hey huge fan of this project. What is some of your upcoming work, refactors, or features you could have some help with contributions on?

[important-new]

Sorry for the slow reply, and thanks for the offer.

Honest answer: don't write code yet. The codebase is mid-refactor (modularization and i18n), so anything landing now has a good chance of being moved or rewritten. Give it roughly two weeks. Once it settles, I'll open real help wanted / good first issue tickets.

What I need more right now is domain feedback. I'm not a home inspector or professional UX designer. I've studied the workflow hard, but studying a trade isn't practising it. The failure mode that worries me isn't bugs — it's a flow and UI that looks perfectly sensible to me but that no working inspector would actually use.

If you can, walk through a job end to end:

order → schedule → agreement/e-signature → on-site capture → report build → delivery → invoice

Tell me where it stops matching reality: what order is wrong, which fields nobody would fill in, what's missing, or what the system lets you do that you shouldn't.

Blunt "this is wrong — here's what actually happens" is more valuable right now than a feature request.

Code contributions will make much more sense once the refactor settles.

[NCHILLC]

Have you tested integration with ISN?

[important-new]

ISN integration not yet developed, I created the feature request. #321

[NCHILLC]

I'm a rookie when it comes to vibe coding, but the learning has been fun and I haven't made my machine smoke, yet. That being said, I'm currently setting up OI for field use and also seeing how ISN integration works, what would be missing, and if I even need ISN. So far, everything looks and feels so much cleaner and UI is intuitive. (I left Spectora for ISN for reasons, but Spectora was smooth) I'm happy to give you feed back for how things work as far as flow and hiccups. How would you want to go about that?

[important-new]

Vibe coding is great for building quick demos or prototypes, but as a project grows and iterates, it can quickly lead to code rot—leaving behind stale code and outdated comments. I've spent a lot of time lately optimizing linting rules and cleaning up technical debt.

I haven't tested OpenInspection thoroughly yet (so expect some bugs), but over the next two weeks, I plan to polish the UI and build out the ISN integration.

If you have time, feel free to deploy OI to your own Cloudflare account or give it a spin at inspectorhub.io. Walk through the inspection workflow ( import templates, create inspection and reports and etc.) and let me know if you run into any bugs or awkward design choices.

[important-new]

Two weeks are up, so here is the promised update.

What shipped since 24 Aug

22 PRs merged upstream. A few highlights relevant to your work:

Statutory forms. Four published field maps are now producing actual documents:

Form | Revision | Blanks bound -- | -- | -- TX TREC REI 7-6 | REI 7-6 | 119/122 FL Citizens 4-Point | Insp4pt 03 25 | 94/95 FL Citizens Roof RCF-1 | RCF-1 03 25 | 35/36 FL OIR-B1-1802 | Rev. 04/26 | 89/96

Each has a gaps ledger, and every page was rasterised and reviewed.

Missing controls. We fixed several UI controls that were visible but non-functional, including filters, buttons, and the full 2FA flow. A role-by-role review also found and fixed several related gaps.

Performance. Your openapi-snapshot.json finding is fixed and led to a wider pass: the eager import graph is smaller, queue/cron no longer pull in the whole API graph, and one page render dropped from 140 to 56 D1 statements. Duplicate reads are now covered by a gate and are at zero.

We also cleaned up routing, AI call tracking, unused schema columns, and documentation screenshots. The screenshots are now generated by actually driving the UI, so broken documented flows fail the docs build.

Help-wanted tickets

I opened #345, a self-contained migration to the shared component primitive, with examples and scope documented.

I had planned to open more, but after checking four other candidates, none turned out to be a good contributor task: they were already fixed, already complete, or intentionally deferred. I would rather have one real ticket than manufacture ten.

If there is a specific area you'd like to work on, tell me and I'll carve out a well-scoped piece with the necessary context.

ISN

We have not tested an ISN integration. It is tracked as #321, but is not scheduled yet.

If you use ISN day to day, I'd especially like to know which parts of the workflow you would actually want synced, and which you would keep separate. That will help determine whether the integration is worth building.

What I still need from you

The most valuable feedback is still an end-to-end workflow:

order → schedule → agreement/e-signature → on-site capture → report → delivery → invoice

Tell me where OpenInspection stops matching reality: what is wrong, missing, awkward, or something the system allows that it shouldn't.

The statutory forms are a good example. I can bind 119/122 fields by reading the TREC form, but only an inspector can tell me whether those fields are actually used the way I think they are.

And sorry I wasn't paying closer attention to the discussion earlier. Thanks again for the feedback — it has already directly changed the codebase.

[NCHILLC]

Sorry for going quiet — here's where I've got to, and a question.

First, to be straight about how far I've got: I haven't been able to run OI as if I were doing a real inspection yet. Two things kept stopping me: Cloudflare errors (the 1102 thread was one of them) and how hard the editor was to use on a phone. So those two are what I've been working on. Also, I'm the vibe coder from earlier in this thread: I built this with a lot of AI help, so weigh it as field observations first and code second.

How I'd use OI: as the report writer only. ISN stays my system for ordering, scheduling, agreements and invoicing. So my feedback covers capture → report, not the stages before and after.

What got in the way of writing a report on a phone:

• Severity couldn't be chosen per defect. Every defect showed the template's category chip ("recommendation"), so every finding wore the same badge that nobody picked. I grade each defect as I find it: Minor / Moderate / Safety-Major.
• Trade, deadline and timeframe aren't part of how I report, and on a phone they're three extra selects per defect.
• Rating levels: IN / NI / NP is what I need, with the defect flag beside the rating rather than inside it. I also found that no template references a rating system (rating_system_id is NULL everywhere), so editing one in the library changes nothing on screen.
• The phone layout was the desktop three-rail layout folded into drawers. I rebuilt it as a stack: inspection → section → item, one screen at a time, with the position in the URL. Android's back button then walks up a level instead of leaving the inspection. More important, a reload lands where you were: opening the camera backgrounds the browser, and a phone low on memory throws the page away.
• Offline: a defect photo taken with no signal was lost, and reloading three taps deep with no signal ended the inspection. With crawlspaces and basements, that's the case I care about most.
• Small things that add up: text too small to read at arm's length, buttons under the 44px touch size, comment previews showing literal <p> tags, no one-tap location (Front / Rear / Left / Right / Attic / Crawlspace…), no dictation button, and the photo annotator needing a typed caption for every mark. I added one-tap stamps: Crack / Moisture / Missing / Damaged. The Measure tool's calibration dialog read as a broken tool.
• Preferences, not requests: I don't use the agent portal (referral tracking lives in ISN), and I don't want AI wording in my reports.

It's unfinished, however, here's what it looks like now:

oi-phone-walkthrough-github.mp4

The question. All of this is in my public repo, NCHILLC/OpenInspection. I've stopped building there, because keeping up with your pace is a losing game and I'd rather this land where everyone gets it. Would you want phone capture upstream? If so, in what shape and what order? I expect some of it will need to change to fit your conventions, and I'd rather send small pieces you've agreed to than a pile you didn't ask for. You offered to carve out an area, and this is the one I'd pick.

On ISN (#321): for report-writer-only use, I think the integration is much smaller than a sync. When a report is published, register its share URL on the ISN order with PUT /orders/addreporturl, and that's it. Things I learned the hard way that belong in #321:

• ISN answers HTTP 200 even on errors, including bad credentials and endpoints that don't exist. Success is status: "ok" in the body, so a client that checks res.ok never sees a failure.
• PUT and DELETE take form-encoded bodies only. Send JSON and every field arrives empty, still with a 200.
• The spec moved to developer.inspectionsupport.com/specs/isn/openapi.json, and the old swagger URL is two versions behind.
• "Footprints" are how ISN tells an integration about new work. They carry information into OI, not reports back out to ISN.

Happy to write that up properly in #321 if it's useful.

[important-new]

Thanks for the detailed write-up. This is exactly the kind of field feedback that's useful to us.

Writing reports on a phone

Yes — I'd definitely like to see phone capture upstream. You're welcome to submit PRs.

Your work on improving the main capture UI and my Speed mode are two different approaches. Your changes focus on making the normal inspection workflow work well on a phone, while Speed mode is a separate approach for faster entry.

I haven't finished Speed mode yet, so I'm not trying to push it as the answer to the mobile workflow. If you have a chance, try it on a computer and tell me what you think from an inspector's perspective.

I implemented the current version with a floating action button in the bottom-right corner (InspectorToolsDock). It expands to Speed mode, Burst camera, Photo studio, and Shortcuts. The overlay itself is already touch-capable, with swipe navigation, large tap targets, long-press jump-to navigation, and an undo toast, although the entry point is currently desktop-only (hidden md:block).

I'd be happy to bring both approaches upstream.

ISN (#321)

If you have time to write those findings up in #321, please do.

[DngrslySkeptical]

Love what you are doing here. And the timing is also serendipitous, since Spectora is hinting at rolling up support for Home Gauge desktop. The company I work for has been using HG for 20 years.

my question. Is there any discussion of developing a native iOS or Android app?

[important-new]

Thanks — and yes, native apps are planned. The order is web first, then iOS, Android and desktop. I'd rather not put a date on it: the web app is still moving quickly (see the 7 Sep update above), and building apps on top of a core that is still shifting would just multiply the surface I have to keep in sync. Once the web side is stable, all three follow.

[NCHILLC]

Problem

North Carolina requires the written report for a prepurchase home inspection of
three or more systems to include a summary page (G.S. 143-151.58(a1)). It must:

• carry this statement verbatim: "This summary page is not the entire report. The
  complete report may include additional information of interest or concern to you.
  It is strongly recommended that you promptly read the complete report. For
  information regarding the negotiability of any item in this report under the real
  estate purchase contract, contact your North Carolina real estate agent or an
  attorney."
• describe any system or component that does not function as intended (allowing
  for normal wear and tear)
• describe any that appears not to function as intended, based on documented
  tangible evidence, and needs further examination by a specialist
• optionally describe safety concerns; all other subject matter belongs in the
  body of the report

Source: https://www.ncleg.gov/EnactedLegislation/Statutes/HTML/BySection/Chapter_143/GS_143-151.58.html

The summary is defined by severity: which findings appear on it depends on the
level assigned to each. Today that assignment exists. Each canned defect carries
a category (Maintenance / Recommendation / Safety by default, tenant-editable
and ordered), and each category has a drivesSummary flag that the report
exposes per defect. The viewer uses it only for a "Defects Only" filter. What is
missing is the summary page itself: the filter is a toggle over the same view,
not a separate page that comes first in both the digital and PDF report; there
is nowhere for the required statement; and the default categories don't line up
with the statute's criteria.

Proposed solution

Build the summary from the severity assignment that already exists, not a
second mechanism:

1. A summary page ahead of the body in the digital report and the PDF. It lists
   only findings whose category has drivesSummary, grouped by category in the
   tenant's existing order. The body keeps everything.
2. The required statement as a company-level setting, seeded with the NC
   wording and printed at the top of the page.
3. Severity levels that match the statute: two it requires (does not function
   as intended; appears not to function and needs specialist evaluation) and one
   it permits (safety concern). Whether that is a seeded preset or documented
   configuration of the existing categories is your call.
4. Opt-in per template or inspection type, since the statute covers only
   prepurchase inspections of three or more systems.

Open question: For my fork, two severity axes exist today: the item's rating (IN, NI, NP, and F) and the defect's
category (Minor, Moderate, Safety/Major) and I would create the summary page by assigned category because the statute's criteria describe findings,
not items. I've got blinders on because I've never done it any other way and I can't think of a better way to describe findings and report them.

Deferred: other states' wording and criteria.
I have layout ideas and can attach a mockup. Happy to build this as a PR if the
scope works for you.

[important-new]

I agree that category-driven is the right approach. The statute describes findings, not item ratings. The existing rating (IN/NI/NP/F) can remain context in the body, while the category determines whether a finding belongs on the summary.

The proposed shape works. A few things to keep in mind for the PR:

1. Summary statement — make it a tenant-level setting, seeded with the exact NC wording. Since the statute requires verbatim text, don't make the default an empty free-text field.

2. Opt-in — per template/inspection type makes sense. The requirement is specifically for prepurchase inspections of three or more systems.

3. PDF — the summary must be a real page before the body, not just a filter/view. Please make sure the PDF follows the same structure.

4. Specialist evaluation — the statute distinguishes suspected failure requiring specialist evaluation from confirmed failure. If your current categories don't distinguish them, that's fine for the first PR, but please document how you're mapping them.

Otherwise, the scope looks good. I agree with deferring other states for now.

Please attach the mockup — happy to review it before you start the implementation.