# PhoSend Intake Book v0.401

## Scope
This book records the current projected architecture, the pieces already standing, the pieces still needed, and the ordinated version line so we do not drift or loop.

## Ordinated Version Line
- v0.101 — first starter plugin skeleton concept.
- v0.201 — current non-hooked bridge state.
- v0.301 — always-hooked bridge state.
- v0.401 — this book snapshot.

## Current Standing Hull
The following pieces are now conceptually in place:

### 1. Front Compliance Engine
- WordPress site front.
- WPConsent Pro installed and active.
- TCF intentionally disabled for now.
- Banner still appears even without the custom WPCode bridge snippet.
- This confirms WPConsent can operate as its own consent interface and essential state recorder.

### 2. Participation Harbor Doctrine
- Visitors may remain in a public/static participation mode.
- Declined or limited consent should not dead-end the visitor.
- The harbor is a deliberate pre-port layer, not a punishment state.

### 3. Port Routing Doctrine
Routing now has three practical front-door states:
- no choice yet
- limited / declined consent
- accepted consent

And a fourth business-state overlay:
- communications opt-in not yet recorded
- communications opt-in recorded

### 4. Intake Doctrine
Actual intake must remain downstream of:
- cookie/privacy handling
- communications consent
- SMS/email operational permissioning

### 5. Verification Doctrine
Telnyx Verify remains the intended OTP engine for phone verification.
Email finalization remains the intended completion signal.

## What We Have Right Now

### A. Proven
- WPConsent Pro is installed and live.
- The consent banner can appear without the custom bridge snippet.
- The starter plugin can be installed directly on the WordPress site by creating files locally on the server.
- The CTA/gate logic can be driven by a WPCode snippet reading browser-side consent state.

### B. Current Bridge Behavior
The current bridge snippet is non-hooked in the stronger sense:
- it reads consent state from the browser cookie heuristically
- it routes the CTA accordingly
- it uses a temporary cookie marker for communications opt-in
- it does not yet authoritatively hook into WPForms submission records or intake table state

This is acceptable as a proving bridge, but not the final doctrine.

## Version v0.201 — Non-Hooked Bridge
Definition:
- browser-side only
- conservative cookie inspection
- temporary `phosend_comms_optin` cookie
- CTA and gate shortcodes available
- no authoritative server-side state coupling yet

Use:
- active test bed
- route proving
- wording and UX proving
- safe temporary harbor while intake table and WPForms hooks are still being shaped

## Version v0.301 — Always-Hooked Bridge
Definition:
- the same visible routing behavior as v0.201
- but the business-state signal is always sourced from a server-side hook path
- the browser cookie becomes optional or secondary
- the bridge always asks the authoritative record first

Planned authoritative inputs:
- WPForms communications consent form submission
- intake table row keyed by email and/or phone
- optional user/session correlation when present

Expected behavior:
- if WPConsent not chosen: require banner interaction first
- if consent limited: harbor route
- if consent accepted and no comms record: communications gate
- if consent accepted and comms record exists: intake

## What Still Needs Built

### 1. WPForms Hooking
Needed:
- intercept the communications consent form on submission
- record consent timestamp, email, phone, consent text version
- set authoritative state in database
- optionally set lightweight browser cookie for convenience only

### 2. Intake State Table Expansion
Current starter table is minimal.
Needed fields include:
- id
- email
- phone
- cookie_state_snapshot
- comms_opt_in
- comms_opt_in_at
- comms_source
- intake_status
- verification_id
- otp_status
- review_status
- created_at
- updated_at

### 3. Telnyx Operational Wiring
Needed:
- send verification on intake trigger
- verify OTP endpoint/page
- resend limits
- expiration handling
- webhook support later

### 4. Admin Review Surface
Needed:
- intake queue
- status view
- verification status
- consent timestamps
- retry visibility

### 5. Enforcement Tightening
Needed:
- stronger WPConsent state parsing or plugin-native data source if available
- fewer heuristics
- more authoritative interpretation of accepted vs limited state

## Practical Build Order

### Phase 1
- stabilize v0.201
- confirm CTA route logic in live tests
- confirm wording and page paths

### Phase 2
- implement v0.301 always-hooked state path
- record communications consent on real WPForms submission
- make CTA ask server-side state

### Phase 3
- expand intake engine
- Telnyx send/verify
- email finalization
- admin queue

### Phase 4
- restartability
- webhook handling
- auditability
- stronger doctrine alignment with the broader PhoSend / FireDance style

## Known Global Flaw Assumption
We must assume the download/file-handoff flaw is global until proven otherwise.
Therefore the working doctrine is:
- prefer directly creatable server-side files
- prefer pasteable snippets
- prefer ordinated inline code and document drops
- do not depend on sandbox file retrieval as a required path

## Operational Rule Against Tail-Chasing
We should not repeatedly retest the same broken transfer path unless a materially different transport is being used.
That means:
- new ordinated versions should be delivered inline first
- downloadable packaging is secondary
- each new version should state exactly what changed

## Next Deliverables
- v0.201 code snapshot: non-hooked bridge
- v0.301 code snapshot: always-hooked bridge
- v0.401 book snapshot: this document

## Delta Rule
Every next ordinated output should explicitly say:
- what was inherited unchanged
- what was added
- what remains projected only

This keeps the line straight and prevents false progress.