IN Infraspace NZ -- Developer Console

What the platform is made of

Every surface InfraSpace advertises, where it is served from, where its source lives, how it is built, and which deploy target carries it. Generated from apps.json and platform.json by the same generator that builds the hub.

5Surfaces

2Live

5Recorded defects

3Fleet services

Surfaces

Measured in your browser, now. Nothing is stored. Cross-origin surfaces are reported as unprobed rather than assumed to work.

Surface	Route	Served from	Source tree	Build	Deploy target
SPMT `spmt` Live Products One SPMT entry, not two. This is the SPMT homepage: sign-in and the portal are reached from it, so the hub does not link them separately. The second surface, 'spmt-site' at /spmt/landing/, was removed from the hub on 2026-09-21 -- it is the platform's own page rather than the product's, it sits inside the SPMT product's source tree (the separation defect), its 'site-root' target is on deploy hold, and it still advertises a retired event property that the owner ruling moved to a site of its own. Its disposal belongs to the SPMT source tree, not to this manifest. [This note is rendered, so it may not name the retired property: the build fails if it does.] Measured 2026-09-24: /spmt/ returns 200 and boots the SPMT application, but the shell it serves loads the bundle index-BAO0lqPB.js, which predates the current source tree. The address is running SPMT, just not this repository's SPMT -- so a fix that has been built but not pushed is invisible to anyone using the site. SUPERSEDED 2026-09-25, and corrected here because the claim it made is now false. As measured on 2026-09-24 it read: the domain root and /spmt/ return byte-identical documents, so infraspacenz.com/ boots SPMT and not the hub. That was true then and is not true now. The root serves the InfraSpace landing page, which links to the hub at /hub/ and to SPMT at /spmt/, so a visitor lands on the platform and chooses. /spmt/ is untouched by that change and still serves the product. The last clause of the old note -- that the platform's own front door is not the address a visitor types -- is the half that is straightforwardly false, and it was the half worth fixing. Re-checked 2026-09-24 and still true: /spmt/landing/ returns 200 while the hub does not advertise it, and the page still carries the retired event brand three times. The removal ruling is therefore measured as intact, not merely remembered -- re-adding this surface would advertise a page that breaches the ruling the removal was made under.	/spmt/ not checked	`/public_html/spmt`	`apps/SmartPropertyManagement`	`npm run build -> deploy-out`	`spmt` spmt
Developer Console `developer-portal` Testing Tools This page. Generated by the same generator as the hub, from apps.json and platform.json, so it cannot describe a platform that does not exist. Owner ruling 2026-09-21, operative half STILL IN FORCE: the hub is mounted at /hub/ and not at the document root. The hub's own index.html is served from /hub/ and this console from /hub/developer/, so the generator's deploy-out tree maps onto the remote /hub/ directory unchanged. Measured before the move (2026-09-20): /hub/ returned 404, so the mount collided with nothing. Re-measured 2026-09-24: /hub/ returns 200 (13355 B) and /hub/developer/ returns 200, so the mount is live and /index.html still serves the InfraDocs landing page untouched. The unsuffixed /developer/ this row previously declared has never resolved, and still does not. The UNIVERSAL half is SUPERSEDED 2026-09-25, and read this before quoting the ruling as settling the root: the ruling settles where the hub is mounted, and it does not settle what answers the root. The owner directed on 2026-09-25 that the root serve an InfraSpace-branded landing page linking to the hub and to SPMT, so the platform now has a front door at the document root while the hub stays at /hub/. Root and hub are two surfaces; the hub does not move. Re-measured 2026-09-24: the deployed hub was built from manifest sha 83bd96950675 at 2026-09-21T07:21:09Z, while the working copy's manifest hashes to 614e74aa5c15. The address is serving an older advertisement than the repository holds, and no gate in this lane can see it -- --check compares the working copy against the manifests, never against the host. Closing that gap is a push of the 'infraspace-hub' target, not a manifest edit.	/hub/developer/ not checked	`/public_html/hub/developer`	`apps/InfraSpaceNZ/site`	`node build-site.mjs --write`	`infraspace-hub` (none yet)
InfraDocs Suite `infradocs` Testing Tools The deploy target 'infradocs' declares remote_root /public_html/infradocs and a verify URL of /infradocs/, but /infradocs/ returns 404 while /docs/ returns 200. The deployed editor and the target that claims to deploy it disagree. Either the target is wrong or the deployment is. One of them must be corrected before this surface is trusted. Re-measured 2026-09-24, unchanged: /docs/ returns 200 (23478 B, the DOC Research Suite) and /infradocs/ still returns 404. The disagreement has now survived two measurements, so treat the target as the wrong half and correct it there.	/docs/ not checked	`/public_html/docs`	`apps/InfraDocs/editor`	`(static tree — deployed as-is)`	`infradocs` (none yet)
SPMT System Console `spmt-console` Live Tools This console is SPMT's own: users, businesses and incident records out of SPMT's Firebase data. It is the product's admin surface, not the platform's. It is reached through a loader shim at /spmt/landing/developer/ which fetches /spmt/index.html and re-injects the SPMT asset tags so the app boots under a second URL. The shim lives inside the SPMT source tree at public/landing/developer/. It works, but the platform should not have to reach into a product's tree to open that product's console.	/spmt/landing/developer/ not checked	`/public_html/spmt/landing/developer`	`apps/SmartPropertyManagement/components/DeveloperPortalScreen.tsx`	`built with the SPMT bundle (npm run build)`	`spmt` spmt
Meetings `infraspace-meetings` Testing In progress Added 2026-09-25, the day this product was first deployed. Measured over HTTPS on the live host: /meetings/ returns 200 with the product shell, and every route under /meetings/api/ returns 503 carrying the same classified refusal -- 'Server database is not configured', naming DB_NAME, DB_USER and DB_PASS. That 503 is the API working rather than failing: it is the endpoint reporting the true state of the host, which is what a fail-loud contract requires, and it is not a transport error dressed as an answer. /meetings/lib/config.php and /meetings/config/database.php both return 403, so the deny rules protecting the library and the future secrets file are honoured by the server and not merely present on disk. Meetings cannot be used until a database exists. The address is up and the client renders, so it is honest to advertise this surface as one being built; it would not be honest to advertise it as usable. The blocker is exactly one thing -- a cPanel MySQL database and a user, stored as DB_NAME, DB_USER and DB_PASS in SecretBox. Measured on the live host: pdo_mysql, pdo_sqlite, mysqli, mbstring and openssl are all present and no extension is missing, so the platform is ready and only the credentials are absent. Running the schema on SQLite is not a substitute, because sql/schema.sql is MySQL-specific and the SQL passes through a single PDO abstraction with no dialect seam to switch on. The 'remote' path on this row is written WITHOUT the /public_html/ prefix that the four sibling rows carry, and that is deliberate rather than an oversight. hosting.rootNote above records the measurement that the deployment account is chrooted into the web root, so a path beginning /public_html/ cannot resolve for it. The siblings are wrong and this row is right; the disagreement is left visible here rather than this row being quietly matched to the majority, because a wrong path that matches its neighbours is still wrong.	/meetings/ not checked	`/meetings`	`apps/InfraSpaceMeetings`	`(served as-is — PHP, no bundle step)`	`(none — deployed by apps/InfraSpaceMeetings/tools/deploy_meetings.py)` (none yet)

Recorded defects

warn SPMT spmt
Measured 2026-09-24: /spmt/ returns 200 and boots the SPMT application, but the shell it serves loads the bundle index-BAO0lqPB.js, which predates the current source tree. The address is running SPMT, just not this repository's SPMT -- so a fix that has been built but not pushed is invisible to anyone using the site.
warn Developer Console developer-portal
Re-measured 2026-09-24: the deployed hub was built from manifest sha 83bd96950675 at 2026-09-21T07:21:09Z, while the working copy's manifest hashes to 614e74aa5c15. The address is serving an older advertisement than the repository holds, and no gate in this lane can see it -- --check compares the working copy against the manifests, never against the host. Closing that gap is a push of the 'infraspace-hub' target, not a manifest edit.
bad InfraDocs Suite infradocs
The deploy target 'infradocs' declares remote_root /public_html/infradocs and a verify URL of /infradocs/, but /infradocs/ returns 404 while /docs/ returns 200. The deployed editor and the target that claims to deploy it disagree. Either the target is wrong or the deployment is. One of them must be corrected before this surface is trusted. Re-measured 2026-09-24, unchanged: /docs/ returns 200 (23478 B, the DOC Research Suite) and /infradocs/ still returns 404. The disagreement has now survived two measurements, so treat the target as the wrong half and correct it there.
warn SPMT System Console spmt-console
This console is SPMT's own: users, businesses and incident records out of SPMT's Firebase data. It is the product's admin surface, not the platform's. It is reached through a loader shim at /spmt/landing/developer/ which fetches /spmt/index.html and re-injects the SPMT asset tags so the app boots under a second URL. The shim lives inside the SPMT source tree at public/landing/developer/. It works, but the platform should not have to reach into a product's tree to open that product's console.
warn Meetings infraspace-meetings
Meetings cannot be used until a database exists. The address is up and the client renders, so it is honest to advertise this surface as one being built; it would not be honest to advertise it as usable. The blocker is exactly one thing -- a cPanel MySQL database and a user, stored as DB_NAME, DB_USER and DB_PASS in SecretBox. Measured on the live host: pdo_mysql, pdo_sqlite, mysqli, mbstring and openssl are all present and no extension is missing, so the platform is ready and only the credentials are absent. Running the schema on SQLite is not a substitute, because sql/schema.sql is MySQL-specific and the SQL passes through a single PDO abstraction with no dialect seam to switch on.

Fleet services

Service	Port	Scope	Purpose	Reachable
HomeDrop hub `homedrop-hub`	`8767`	lan	Hub runtime: mirror, beam, radar, deck control, and the InfraDocs document route.	not checked
StreamLine coordinator `streamline-coordinator`	`8768`	lan	Workspace coordinator: service registry, boot plan, focus record, agent portal and token spend.	not checked
InfraDocs host `infradocs-host`	`8770`	lan	InfraDocs host API: document store and the contract the editor reads.	not checked

These run on the LAN. Open this page from the LAN to probe them; from the public internet the check reports that it cannot run, not that the services are down.

Hosting model

infraspacenz.com · document root /

InfraSpace hosts and maintains every site deployed under it. Each product keeps its own banner, its own source tree and its own release path, so a change to one product cannot reach into another.

Corrected 2026-09-25. This read /public_html, which can never resolve: the deployment account is chrooted into the web root, so its FTP root IS the document root and a path beginning /public_html has no meaning to it. That chroot is the measured cause of the older deploy targets failing with 550 errors. The value on the line above is now the true one. It was rendered before and it is rendered still, so the wrong path was a visible claim rather than a private one -- which is why it is corrected here and not annotated away.

What this console shows, and what it does not

Measured, not remembered. Every probe result on this page is measured by your browser, at the moment you press the button. Nothing is stored, cached or replayed. A probe that cannot reach a surface reports that it could not reach it — it never reports a plausible success.

Not published. Host addresses, cPanel account names, origin IPs and every credential are held locally in the deploy tables and in SecretBox. They are deliberately absent from this page. Their absence is enforced by build-site.mjs, which fails the build if any value listed in local.mustNotPublish appears in the generated output.

Not shown. This console does not show user accounts or account records. Those are live platform data held in Firebase, and serving them requires an authenticated console with a real backend and Firestore rules. Until that exists, this page shows the platform's structure and not its records. That gap is stated rather than filled with a lookalike.