Co.PropertyTeam wikiCo.Property20 October 2026
Press slash to search. Arrow keys select a result.
Internal knowledge
Browse the wiki

Reference

Service directory

Checked

This directory names the approved service destinations used around Co.Property. Every destination requires an existing authorised account or approved auth; the wiki never stores tokens, credentials, or private logs.

Download page Markdown
Interactive mapSelect a node to read its explanation. Use Work on this beside the section to prepare a change.
Service directory: approved destinations, not shared access diagramStaff and public web surfaces, provider consoles, infrastructure consoles, the authenticated source API, and loopback mini viewer paths have different access and action boundaries.Staff & web — Service directory: approved destinations, not shared accessStaff & webProvider consoles — Service directory: approved destinations, not shared accessProvider consolesInfrastructure — Service directory: approved destinations, not shared accessInfrastructureApproved-auth API — Service directory: approved destinations, not shared accessApproved-auth APIMini viewer tunnel — The Mac mini: authoritative writer and local operating coreMini viewer tunnel
The directory groups services by purpose and access boundary.Solid · information flow
Read the diagram as text

Staff and public web surfaces, provider consoles, infrastructure consoles, the authenticated source API, and loopback mini viewer paths have different access and action boundaries.

  • Staff & web → Service directory: approved destinations, not shared access
  • Provider consoles → Service directory: approved destinations, not shared access
  • Infrastructure → Service directory: approved destinations, not shared access
  • Approved-auth API → Service directory: approved destinations, not shared access
  • Mini viewer tunnel → The Mac mini: authoritative writer and local operating core
What it does

Provide a concise, safe index of services and explain which ones are staff views, provider consoles, deployment consoles, private admin surfaces, or authenticated APIs.

Responsibility

Each service owner controls access through its approved account and permission model.

Next step

Use an existing authorised account; ask for access through the owner/admin route.

Approved destinations

Service directory

Existing authorised accounts are required. These links do not carry access material and the source API must only be used with approved authentication.

Project

Staff & web

Infrastructure

Access

Provider

Communications

Controlled API

Find the right service by the work it supports

Checked

Project and staff surfaces: GitHub repository, staff PWA, Co.Property website, and Academy.

Read the details

Project and staff surfaces: GitHub repository, staff PWA, Co.Property website, and Academy. Infrastructure and access consoles: Cloudflare dashboard, Vercel dashboard, and Tailscale admin. Provider and communications consoles: Hospitable, Turno, PriceLabs, LINE manager, and LINE developers console.

The source API is `https://coproperty-office-api.coproperty-office.workers.dev` and requires approved authentication. The directory lists it as a controlled source, not an endpoint to call from this static site.

Current
Checked — links are a navigation aid; every destination still requires existing authorised access.
Proposed next state
Review link ownership and access wording whenever a service changes.
Expected outcome
A reader can identify the relevant authorised surface without treating the wiki as a credential vault.
Checks to include when changing this section
  • Check service URLs exactly match the approved directory and use HTTPS.
  • Check all external link elements include rel="noreferrer" or equivalent safe handling.

A reachable sign-in page is not an approval to act

Checked

Existing authorised accounts are required for every listed service.

Read the details

Existing authorised accounts are required for every listed service. An installed CLI, an open browser session, or a familiar dashboard does not prove a teammate is the approved identity for a task. This is especially important for Codex on the mini, provider consoles, and deployment dashboards.

The wiki deliberately avoids tokens, credentials, API probes, and private evidence. If a task needs access, use the owner or admin approval route and record only the safe outcome in the appropriate authorised system.

Current
Checked — the access condition is explicit and no secret material is included.
Proposed next state
Keep privileged actions outside static documentation and require individual approved authentication.
Expected outcome
Links help navigation without leaking access material or implying authority.
Checks to include when changing this section
  • Search static exports for credential-like terms and confirm no values are present.
  • Check source API text says approved auth is required and makes no unauthenticated request.

Keep operational paths useful without publishing private material

Checked

The loopback mini viewer can be reached through an approved SSH tunnel at port 8790 for `/admin`, `/planning`, `/health`, `/reports`, and `/tv`.

Read the details

The loopback mini viewer can be reached through an approved SSH tunnel at port 8790 for `/admin`, `/planning`, `/health`, `/reports`, and `/tv`. Keep it described as a secured operator path, not a public web service.

Do not add runtime databases, credentials, private logs, internal QA evidence, or an endpoint that executes a contribution request to the wiki. The static site’s role is orientation and safe drafting.

Current
Checked — the directory is intentionally bounded to safe links and explanations.
Proposed next state
Reject documentation additions that would turn the wiki into a credential, runtime, or execution surface.
Expected outcome
The shareable static wiki remains useful without expanding the exposure of internal systems.
Checks to include when changing this section
  • Check generated files contain no API client, execution endpoint, or runtime database artifact.
  • Check mini viewer paths are paired with the SSH-tunnel requirement.

Apply with care

A concrete safe example

Example, responsibilities & checklist

A safe directory use

Open the staff PWA only with an approved account. If a dashboard issue needs investigation, use the directory to identify the relevant provider or console, then follow its current approved access procedure. Do not paste tokens into the wiki or a drafted prompt.

Responsibilities

  • Each service owner controls access through its approved account and permission model.
  • A contributor uses their own approved identity and does not share or request secrets in documentation.
  • The source API requires approved authentication and must not be probed anonymously.
  • The mini viewer remains loopback-only through a secured SSH tunnel.

Checklist

  1. Use an existing authorised account; ask for access through the owner/admin route.
  2. Never publish, paste, or request tokens, private keys, credentials, or private logs.
  3. Treat authenticated API and provider consoles as controlled surfaces, not documentation examples to call.
  4. Use a secured tunnel for mini viewer paths; do not expose loopback endpoints publicly.
Expected outcome

A reader can find the right destination while understanding that access and action still require individual authorisation.

Traceability without sensitive material

Source pointers and exports

This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.

Documentation references
  • Handoff / pages/infrastructure.html
  • Handoff / pages/access.html
  • Handoff / START-HERE.html
Page MarkdownPage context JSON