# Ghostmesh Access Posture Decision V01

Issue: [#188](https://github.com/pinklon/ai-capability-discipline/issues/188)

Date: 2026-06-30

Repository: `pinklon/ai-capability-discipline`

Baseline commit: `2866a7a71d6467b984fe283bbc2b6e781000ba4f`

## Purpose And Decision Boundary

This decision records whether `ghostmesh.ai` should remain split/public, move fully behind Cloudflare Access, or adopt a hybrid posture before richer enrichment-source lanes are enabled.

This is a publication, access-boundary, and controlled-sharing decision. It does not implement full-site Cloudflare Access, route-level Access changes, Cloudflare configuration, Cloudflare CLI or API use, company-specific content, uploaded/session-source behavior, external/current context mode, provider/model configuration, source-grounded chat runtime behavior, source registry mutation, approved source-set mutation, package-authority mutation, issue relabeling, issue close or reopen, follow-up ticket creation, #269 or #271 reopen, or `codex-automerge`.

Recommendations in this note are implementation guidance only. Any Cloudflare Access implementation remains a later owner-approved lane.

## Current Baseline

| Surface | Current posture | Decision relevance |
|---|---|---|
| `https://ghostmesh.ai/` | Public Cloudflare Pages production surface. | Public controlled-sharing entry point for field guidance and package navigation. |
| Public approved corpus and `docs/context-pack/` mirror | Public, deterministic mirror of root `context-pack/`. | Enables inspection, citation, package portability, and source-grounded public-corpus reasoning. |
| `https://ghostmesh.ai/source-grounded-chat-proof` | Protected by Cloudflare Access or equivalent external control before broad use. | Prevents uncontrolled provider-backed proof use while preserving public corpus inspection. |
| `/api/source-grounded-chat` | Protected provider/API boundary or controlled denial in unauthenticated checks. | Keeps provider-backed execution behind server-side and access-control gates. |
| `https://www.ghostmesh.ai/` | Redirects to apex. | Redirect and fallback behavior must remain explicit in any posture change. |
| GitHub Pages fallback | Fallback, historical, or troubleshooting surface, not production smoke authority unless separately refreshed. | Should not become an implicit private-data or protected-proof surface. |

## Options Evaluated

| Option | Description | Strengths | Costs and risks |
|---|---|---|---|
| Keep current split posture | Public static site, public approved corpus, protected proof/API routes. | Preserves discoverability, package transparency, citation inspection, and low-friction controlled sharing. Keeps provider-backed risk isolated. | Public and private artifact boundaries can become confusing as future less-public sources arrive. Requires strong navigation and validation so private lanes do not leak into public corpus. |
| Protect the entire site | Put `https://ghostmesh.ai/*` behind Cloudflare Access. | Simple access rule for private beta, internal evaluation, and company-specific material. Reduces accidental public exposure risk if private sources are introduced later. | Removes public playbook surface, weakens SEO and discoverability, blocks public artifact inspection, complicates fallback links, and can make the governed package look like an internal app instead of field guidance. |
| Hybrid | Keep a public landing and approved public package surface while protecting artifacts that need access control, proof/API, and future private enrichment lanes. | Preserves public identity and package inspection while creating a clear private lane for provider-backed and less-public material. Aligns with future uploaded/session-source and external/current context modes without treating all package material as private. | Requires explicit public/private navigation, route inventory, validation coverage, redirect checks, and later #182 implementation discipline. |

## Recommendation

Adopt a hybrid posture as the target decision.

Recommended target:

1. Keep a public landing surface and public approved package/corpus material for `ghostmesh.ai`.
2. Keep provider-backed proof/API routes protected.
3. Treat future private artifacts, company-specific content, uploaded/session-source behavior, and external/current context mode as protected lanes unless an owner explicitly approves public release.
4. Use explicit public/private navigation labels so readers can tell which surfaces are public field guidance and which require Access.
5. Keep #182 as the later protection/access-control implementation lane, narrowed to route inventory, public/private navigation split, Access-protected route set, redirects, fallback-domain treatment, and validation/smoke receipts.

Do not move the entire site behind Access now. Full-site protection should remain a future option only for a private beta or controlled-access evaluation where public discoverability is intentionally paused.

## Required Coverage

| Topic | Decision |
|---|---|
| Controlled-sharing posture | public controlled-sharing remains valid for approved package material. Protected sharing is required for provider-backed proof, private enrichment, company-specific content, and session-source behavior. |
| Public vs private artifact identity | Public artifacts need stable identity, source paths, context-pack links, hashes, and non-approval boundaries. Private artifacts need explicit Access requirement, source authority boundary, and receipt trail before exposure. |
| Source/corpus publication | Approved package corpus can remain public. Less-public, private, company-specific, uploaded, or current/external enrichment sources must not enter the public approved corpus by default. |
| SEO/discoverability | Keep public landing and approved package pages discoverable. Do not depend on SEO for protected proof/API or private enrichment lanes. |
| Provider-backed proof/API risk | Keep proof/API protected by Access or equivalent control, server-side provider boundaries, method/body/source-count checks, deterministic refusals, sanitized errors, and manual or protected provider smoke. |
| Future company-specific content | Treat as protected by default. Do not publish in public corpus or landing pages without a separate owner-approved release decision and validation receipt. |
| Uploaded/session-source behavior | Treat uploaded or pasted sources as session-provided material, not approved package corpus, durable corpus ingestion, or enterprise source authority unless separately approved. Protected handling is required before implementation. |
| External/current context mode | Keep current/public enrichment separated from package authority. External/current context mode should remain protected or Preview-gated until source authorization, runtime smoke, and validation receipts exist. |
| Validation and smoke checks | Keep public static smoke for landing, approved package pages, context-pack mirror, downloads, hashes, redirects, and fallback-domain posture. Keep protected smoke for proof/API and private lanes. |
| Docs and receipts | Every posture change needs a route inventory, decision note update, validation receipt, published-site contract coverage, and PR body boundary confirmations. |
| Redirects and fallback domains | `www` redirect, apex production authority, and GitHub Pages fallback must be documented in the route inventory. Fallback domains must not bypass protection for protected surfaces. |
| Relationship to #182 | #182 should be the later implementation lane, not this decision. It should remain open or be narrowed to implement the hybrid protection/access-control surface after this decision lands. |

## Public Surface Recommendation

Public surfaces should include:

- public landing and package orientation pages
- approved public playbook and package artifacts
- public context-pack mirror under `/context-pack/`
- public artifact manifest, hashes, and portable export links that are already approved for controlled sharing
- public documentation that states field-guidance, non-policy, non-production, and non-enterprise-approval boundaries

Public surfaces should not include:

- provider-backed API execution
- private or company-specific content
- uploaded or pasted user source material
- raw private enrichment sources
- protected proof run telemetry from authenticated sessions
- credentials, cookies, service tokens, provider keys, raw request headers, raw response headers, or secret-bearing redirect URLs

## Protected Surface Recommendation

Protected surfaces should include:

- source-grounded proof page when it can trigger or demonstrate provider-backed execution
- `/api/source-grounded-chat` and any provider-backed API route
- future private artifacts, company-specific content, and protected enrichment-source lanes
- uploaded/session-source workflows
- external/current context mode when it uses live retrieval, provider execution, or less-public source sets
- operator receipts that expose implementation-specific external-account details

Protection should be route-scoped and validated, not assumed from naming alone.

## Future-Private Surface Recommendation

Future-private surfaces should be explicitly labeled as private or Access-required before implementation. A future lane should define:

- route inventory
- artifact identity and source authority
- public/private navigation text
- Access route set
- fallback-domain behavior
- validation commands
- smoke evidence
- residual risks

No private source should become public because it is useful to an assistant, a context-pack, or a generated artifact.

## #182 Implementation Guidance

#182 should remain the next implementation lane only after this decision lands. The recommended #182 scope is:

1. Inventory all public, protected, and fallback routes.
2. Define a hybrid public/private navigation split.
3. Preserve public approved package and context-pack inspection.
4. Keep proof/API protected.
5. Add or update published-site and protected-route smoke checks.
6. Record redirect and fallback-domain behavior.
7. Add a validation receipt that proves no private lane is accidentally public.

#182 should not become a broad Cloudflare rebuild, provider/model change, source registry change, approved source-set change, package-authority change, uploaded/session-source implementation, external/current context implementation, or company-specific content lane.

## Decision Matrix

| Criterion | Split public | Full-site protected | Hybrid |
|---|---:|---:|---:|
| Preserves public field-guidance identity | Strong | Weak | Strong |
| Supports private beta | Limited | Strong | Strong for protected lanes |
| Keeps approved corpus inspectable | Strong | Weak | Strong |
| Reduces accidental private exposure | Moderate | Strong | Strong if route inventory and validation are enforced |
| Supports SEO and discovery | Strong | Weak | Moderate to strong |
| Keeps provider/API risk controlled | Strong for protected routes | Strong | Strong |
| Supports uploaded/session-source future | Weak without new routes | Strong | Strong |
| Supports external/current context future | Moderate | Strong | Strong |
| Implementation complexity | Low | Moderate | Moderate |
| Best fit for current package posture | Partial | Poor | Best |

## Validation Expectations

This decision artifact should be validated by:

```bash
python3 -B scripts/build_context_pack.py
python3 -B validation/scripts/check_ghostmesh_access_posture_decision.py
python3 -B validation/scripts/check_context_pack.py
python3 -B validation/scripts/check_minimal_external_chat_proof.py
python3 -B validation/scripts/check_published_site_contract.py
python3 -B validation/scripts/run_all.py
git diff --check
```

If `check_published_site_contract.py` or `run_all.py` fails only because the local static server cannot bind in the sandbox, rerun through the established local-server privilege path and record both the initial failure and privileged rerun result.

## Explicit Non-Implementation Confirmation

This issue does not implement full-site Cloudflare Access.

This issue does not implement route-level Access changes.

This issue does not use Cloudflare CLI or API.

This issue does not change Cloudflare configuration.

This issue does not publish company-specific content.

This issue does not implement uploaded/session-source behavior.

This issue does not implement external/current context mode.

This issue does not implement provider/model configuration changes.

This issue does not implement source-grounded chat UX or runtime behavior changes.

This issue does not remove route-level Access protection.

This issue does not make production, GxP, tool, SaaS, enterprise-policy, or enterprise-approval claims.

This issue does not relabel issues.

This issue does not close or reopen issues.

This issue does not create follow-up implementation tickets.

This issue does not reopen #269 or #271.

This issue does not apply `codex-automerge`.