v2.2.0

TigerInstall 2.2.0 — engine v1.3.0 (default ComingSoon holding page)

v2.1.1

2.1.1: the agent key reaches the finish screen and the credentials file

With one step per request the request that minted the key was not the one that finished; the
finish screen said 'not enabled' while /mcp was on with a credential nobody had. The minting
request stashes the token in the job file (0600, above the docroot, deleted at finish); the
finish screen and the credentials file read it from there. Engine 1.2.3 (partial runs carry
their steps' extras). Invariant added.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L8p9pLJ3DFstG3xZuh2QgZ

v2.1.0

2.1.0: six screens (Site → What to install → Install), one engine ste…

v2.0.2

2.0.2: what to install — theme, modules and skill packs from TigerCat…

v2.0.1

2.0.1: the handoff — an assistant stops at the details screen, the pe…

v2.0.0

2.0.0: the web installer is tiger-headless

The wizard holds no install logic. build.php inlines the engine from its tagged release
(ENGINE_VERSION) into dist/tiger-install.php — still one file for the user. Screens:
Requirements (engine hostRequirements) → Location → Details (database + admin, one form; the
engine validates the spec and proves the database before anything is written) → Install (one
engine hop per request, progress on screen, resume from any failure, manual upload after a
download failure) → Done (self-delete). The spec lives in a 0600 job file above the docroot;
the database password never rides in a hidden field. Invariants enforce all of it.

Proven on host3 (authors account, symlink off): wrong password refused before writing; four
hops; a failure mid-way resumed from that step after the engine fix; self-deleted; site live.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L8p9pLJ3DFstG3xZuh2QgZ

v1.2.1

• Publishes every bundled module's assets after migrating, so a fresh no-shell install serves module JS from the first page load (TIGER-123). Guarded for cores older than 1.6.2.

v1.2.0

Two things you cannot recover from after the finish screen — because the installer deletes itself.

Confirm email + confirm password

A typo in the one email address that owns the install is unrecoverable from that screen: the password reset goes to the address that was typed wrong. Both fields are now confirmed, and validated before the download and migration run, so nobody waits through the slow work to be told they mistyped.

Email match is case-insensitive — retyping with different capitalisation isn't a typo. Password match is exact. Password strength stays Tiger's rule, so there's one authority for it rather than two that can disagree.

A credentials backup file

Afterwards the database password lives only in local.ini above the document root, and the agent access key is shown exactly once. Close the tab and they're gone.

The finish screen now offers one file with the admin login, database details, paths, and the agent key.

It's served as a data: URI on a plain <a download>. No JavaScript — and, the actual reason it's built this way, nothing sensitive is ever written to the server. Writing that file into the document root would publish every secret in the install to anyone who guessed the filename, and it would outlive the installer that created it. A file that never exists on disk can't be fetched and can't be left behind.

Tested

83 assertions, CI green on PHP 8.1–8.5.

v1.1.0

The agent handshake. A browser-aware AI client can now drive the installer and be handed a working, scoped credential at the end — without weakening a single default.

Machine-readable state on every screen

Every page carries a JSON block so a client can tell where it is and whether the last action worked, without scraping prose:

<script type="application/json" id="tiger-install-state">{ "step": "...", "status": "..." }</script>

status alone answers "did that work?" — blocked (an unmet requirement), error (retryable, with a stable slug), ok (only on finish). The requirements step reports each check with ok / required / fix.

The connect handshake

A fresh Tiger is deliberately unreachable by an agent: /mcp is off and tokens are normally minted by an authenticated admin. The installer's finish step is the one moment a human is present, authenticated, and making a deliberate choice — so that is where the credential is handed out.

Tick "Let the assistant that installed Tiger manage it" on the admin step. It can be pre-ticked with ?agent=1, but it is always visible before you submit and can be turned off. On success the finish screen shows a scoped key once, and the state block carries it alongside the /mcp endpoint and the /mcp/admin URL where it can be revoked.

Scope is the curated starter set, org-scoped. tiger.api.discovery is untouched. There is no callback URL — the key appears on the installer's own screen and nowhere else.

If the box is not ticked you get exactly today's defaults, and the screen tells you how to enable it later.

Also

• CI: lints on PHP 8.1–8.5, the range a cPanel host is likely to offer, plus 61 assertions guarding the installer's invariants — one file, no dependencies, no shell calls, and no callback field of any kind.
• Release artifacts are now built by CI rather than assembled by hand.

1.0.3

Two installer fixes, both found by AI review and each confirmed against real code before fixing.

Provisioning no longer destroys the secrets it just minted (TIGER-77). do_provision() rebuilt local.ini from scratch on every call, writing only the DB block — so tiger.crypto.key and tiger.security.pepper were wiped, and provisionSecrets() minted replacements because they were now absent. It runs on both the admin and finish steps, so a normal forward pass rewrote the file twice; go back and forward once, or retry finish after an error, and the pepper rotated after the owner's password had been hashed with the old one — locking the operator out of the site they had just installed. It now merges instead of replacing, writes atomically, and reports write failures instead of swallowing them.

Downloads are verified or refused (TIGER-78). Checksum verification was skipped when a release carried no .sha256, and skipped again when the fetch returned empty — exactly the failures the digest exists to catch. An automatic download now requires a matching 64-hex digest and stops before extraction otherwise. Manual upload is unchanged.

Every published release carries its checksum, so automatic installs are unaffected.