Non-git onboarding: WordPress (and other no-git) users cannot get code into Gluecron#209

Owner question 2026-08-08: "so we can't onboard wordpress users?" Correct — today the only ingress is a git URL import or git push. WordPress users (wp-admin + hosting file manager, no git) are locked out entirely. Verified: no zip upload, no FTP/SFTP pull, no WP integration anywhere in src/.

Key insight: git is ONLY the ingress problem. Once a repo exists, the MCP write tools (gluecron_write_file, gluecron_atomic_multi_file_commit) let agents work entirely over API — no git client needed. The gap is the on-ramp, in three shippable tiers:

Tier 1 — Zip upload import (build first, smallest, universal). /import/zip: upload an archive → new repo + initial commit ("Imported from archive"). Serves WP users (every host's file manager exports wp-content as zip) and ANY no-git user. Reuses importOneRepo's post-clone plumbing (DB row, secret scan, health). Guards: size cap (500MB, match bulk), zip-slip path traversal protection, strip .git dirs from the archive, reject nested bombs (entry count + expansion-ratio caps).

Tier 2 — SFTP pull import + re-sync. Enter host/credentials → Gluecron pulls a directory (e.g. wp-content/) into a repo; a "re-sync" button diffs the live server against the repo and commits drift onto a branch as a PR ("changes made on the server"). Credentials via the encrypted org-secrets infra. This makes Gluecron the change-tracking layer over a site edited by many hands — a real WP pain point.

Tier 3 — WordPress connector plugin (the actual product for WP). A wp-admin plugin: registers the site against a Gluecron repo (PAT), pushes theme/plugin file changes up as commits, and — the payoff — DEPLOYS merged PRs back to the live site. Closes the full loop: WP user asks the agent for a change in plain English → spec-to-PR → gates + review → merge → plugin syncs to the site. No git, no terminal, ever. (Owner already has Intelligent-Plugin-Conflict-Detector — natural synergy: run it as a gate for WP repos.)

Also cheap and worth doing alongside Tier 1: the single-repo /import accepts any git URL already — surface that ("GitLab, Bitbucket, any git host") in the UI copy, and add a "no git? upload a zip" link.

Onboarding + Agent Brief should branch on repo kind: a WP-imported repo's brief should describe the zip/plugin loop, not git push.

STATUS: spec only — nothing built, nothing to ship. No branch or PR exists for this. It is a design plan for the WordPress / non-git on-ramp (STRATEGY-30 move #6).

Decision needed from the owner: priority only —

• "build next" → Tier 1 (zip upload import) gets its own focused session, security first (zip-slip, archive bombs);
• "queue it" → it joins the repair-agent backlog behind #208 and #206;
• "later" → it stays a spec, nothing happens.

Nothing in this issue changes the platform until an implementation PR exists and is merged.

Going forward, every issue the agent files opens with a STATUS line like this one, so "is this shippable?" is always answerable from the issue itself.