# ppradhan.com — PPPHP marketing site

The public site for **https://ppradhan.com**. It lives inside this repository so
it travels with the product: when a feature ships, the page describing it is one
commit away, not in some other place nobody remembers to update.

## What is here

```
ppradhan.com/
├── index.html              the entire site — one self-contained file
├── logo.svg                the original mark, as currently served at ppradhan.com
├── README.md               this file
└── assets/brand/
    ├── mark.svg            primary mark (no drop shadow — composites cleanly)
    ├── mark-mono.svg       single colour, inherits currentColor
    ├── favicon.svg         small-size / app-icon variant (see note below)
    └── wordmark.svg        horizontal lockup: mark + "PPPHP"
```

## Documentation (`docs/`)

`docs/` is **generated** from the in-app Help. Do not hand-edit it — edit the
source under `help/<topic>/index.php`, then regenerate:

```
php tools/build-public-docs.php
```

### What is never published

`licensing` and `updates` are excluded on purpose. They document the signing key,
the integrity manifest, protected builds and the pairing protocol — publishing
them would hand anyone a bypass roadmap. They stay inside the app, behind the
owner gate.

The generator refuses to run if a private topic is ever also listed as public,
and it strips links pointing at private topics so no page ships a dead link.
After regenerating, it is worth re-running the leak check:

```
grep -ril "signing key\|LicenseTrust\|ProtectedCode\|pairing code" ppradhan.com/docs
```

That should print nothing.

## Deploying

Copy the contents of this folder to the web root of `ppradhan.com`. That is the
whole procedure — there is no build step, no dependencies, no server-side code,
and nothing to install.

```
rsync -av --delete ppradhan.com/ user@host:/path/to/ppradhan.com/public_html/
```

It is plain static HTML, so it works on any host and caches well behind a CDN.

## Why one file

`index.html` carries its own CSS and its tiny bit of JavaScript inline. That is a
deliberate choice for a page like this:

* nothing to compile, so it cannot break in transit;
* one HTTP request for the page, which is faster than any bundling would be;
* it can be opened straight from disk to preview a change.

If it ever grows past comfortably editable, split the CSS out then — not before.

## Design notes

* **Light and dark** follow the visitor's system setting via
  `prefers-color-scheme`. Both are styled; neither is an afterthought.
* **The product "screenshots" are CSS**, not images. They stay sharp on any
  display, weigh nothing, and — importantly — never go stale when the real UI
  changes. Swap them for real screenshots only if you are willing to re-shoot
  them every release.
* **No web fonts.** System fonts render instantly and match the visitor's OS.
* Verified with no horizontal overflow at 375 px and 1280 px.

## A note on the favicon

The twin-P mark is strong at medium and large sizes, but the two P strokes merge
into each other below roughly 24 px — which is exactly the size a browser tab
uses. `assets/brand/favicon.svg` therefore uses a solid tile with a single bold
P, in the same gradient family, so it still reads as the same brand beside the
full mark. Use `mark.svg` everywhere there is room, and `favicon.svg` only where
there is not.

## Keeping it honest

Every capability claimed on the page is one that PPPHP actually ships. If a
feature is removed or changed, update the copy in the same change — a marketing
page that overstates the product costs more in support than it wins in sales.
