Test plan — maxelmagnets.com

Onboarding survives a full pass - all seventeen fields

This is the whole reason the plan exists. Tim onboarded FerroSpring six times and lost it every time. Two separate causes were fixed: an exact-match filter that binned any answer a human would actually type, and three screens that kept answers in the browser instead of on the server. Both fixes are proven on this site and unproven on Tim's.

1. Sign in as the owner of maxelmagnets.com and start onboarding from phase 1.
2. Answer every field, including the four newest: your top three ideas, your last 5–10 good leads, how much time you will spend, and whether you will write original content.
3. Deliberately type natural phrases, not menu words — “Leads”, “Email marketing”. The old filter discarded exactly these.
4. Finish the phase. Do not clear your browser first — that would mask the bug.
5. Then sign out, clear site data, and sign back in. Anything kept only in the browser dies here.

Every field is still there after the cache is cleared, because it was stored on the server.

python3 -c "import io,json;w=json.load(io.open('/opt/autoengine/workspaces/maxelmagnets.com.json'));ik=w['intake'];print(len(ik),sorted(ik))"

The reason these four had never been stored has been found and fixed, 20 Aug. The submit step built its payload by hand and simply left them out, so they were collected and then dropped on the floor. The parser has since been exercised directly with all four and returns 17 stored fields. This is still their first run through the actual interface, which is the half worth watching.

Feed the engine writes to the server, not the browser

This card silently wrote to localStorage. Tim named four competitors aloud on the 19 Aug call — Bunting, Foresee, Quadrant and Hirst — that our own 23-company research had missed. Typed into the old card, all four would have died in his browser.

1. Open the feed-the-engine card at the end of onboarding.
2. Add one competitor with an obviously unique name, e.g. ZZ Test Magnetics.
3. Do not reload. Check the file on disk first, then reload and confirm it is still shown.

The new name appears in intake.competitors on disk within a second or two.

python3 -c "import io,json;print(json.load(io.open('/opt/autoengine/workspaces/maxelmagnets.com.json'))['intake']['competitors'])"

Use a junk name you can recognise and remove. Do not test this on someone else's site. A test value was written into Tim's FerroSpring workspace on 19 Aug and had to be cleaned out by hand.

Operations settings persist - the whole of phase 3

Cadence, team roles and the meeting schedule were browser-only. Everything Tim defined Operations to be would have vanished on a cleared cache, and the server-built dashboard could never have read it.

1. Open phase 3 and change the meeting time to something distinctive, e.g. 07:45.
2. Save, then clear site data and sign back in.
3. Confirm the dashboard header shows the changed time, not the old one.
4. Set it back to 08:00 when finished.

The change is on the workspace and the dashboard reflects it without a re-onboard.

python3 -c "import io,json;print(json.load(io.open('/opt/autoengine/workspaces/maxelmagnets.com.json')).get('ops'))"

Phase 4 is a confirmation screen and nothing more

Tim's clearest instruction: “You keep mixing the work output in the setup.” Phase 4 used to render a readiness score, a strongest/weakest discipline and a “next 10X” recommendation — generated work, inside setup. It was rebuilt as an order-review screen.

1. Reach phase 4 after completing 1–3.
2. Read every element on the page.

You see only what you entered, plus the booked meeting. No score, no ranking, no recommendations, no proposed work. If any generated output appears, the test fails and the item goes straight back on the huddle.

Visual check. Confirm the summary matches the SERVER record, not a browser draft:
python3 -c "import io,json;print(json.load(io.open('/opt/autoengine/workspaces/maxelmagnets.com.json'))['intake'])"

The audit is stable and repeatable

A score that moves on its own is worse than no score. Tim will re-run this in front of everyone, and it has to land in the same place.

1. Note the current scores below.
2. Run the SEO/AEO analysis again without changing the site.
3. Compare check-by-check, not just the headline number.

51 checks again, and the same pass/warn/fail split unless the site genuinely changed. Current baseline: 30 pass, 12 warn, 9 fail, overall 66.

python3 -c "import io,json,collections;a=json.load(io.open('/opt/autoengine/workspaces/maxelmagnets.com.json'))['analysis'];print(a['scores']);print(collections.Counter(c['state'] for c in a['checks']))"

This site must NOT be able to publish - and that is correct behaviour

maxelmagnets.com is not on the publish whitelist. Shipping requires both a whitelist entry and a webroot on our server. The whitelist holds the near-identical maxelmag.com, which is exactly the kind of pair that hides a mistake.

1. Approve any deliverable that would normally publish.
2. Confirm the engine offers a preview or a manual instruction rather than shipping.
3. Confirm no file appears or changes under the webroot.

A clear message that this site is not hosted here, and no write to /var/www/maxelmagnets.com/. A silent success would be the serious failure.

ls -la --time-style=full-iso /var/www/maxelmagnets.com/ | head -20

This is a negative test. Passing means nothing happened.

Positive control - a real publish, on a site that is allowed

T6 proves it refuses. This proves it can. Without both, a refusal is indistinguishable from the feature being broken.

1. Pick a whitelisted magnetics site — maxelmag.com or polymagnets.com — and approve one technical fix (a title, a meta description, or schema).
2. Watch for the snapshot, the sitemap rebuild and the IndexNow ping.
3. Then roll it back and confirm the page returns to its previous state.

The live page changes, a snapshot exists from before the change, the sitemap is newer than the page, and rollback restores it exactly.

ls -la /opt/autoengine/snapshots/ | tail -5
curl -sI https://maxelmag.com/sitemap.xml | head -3

Rollback is the half nobody tests. If it cannot be undone, it should not be sold as safe.

An admin is warned before writing into someone else's site

Both ownership helpers used to let admins through unconditionally, and Paul is an admin. That is how one session could have overwritten Tim's FerroSpring. It now returns 409 and demands an explicit confirmation, and logs every crossing that is confirmed.

1. Signed in as an admin, attempt a write against ferrospring.com (owned by Tim) without a confirmation flag.
2. Confirm the refusal explains whose site it is.
3. Re-send with confirm_owner=true and confirm it proceeds AND is logged.

First attempt: 409 with needs_confirm. Second: succeeds, and an entry naming the admin appears in that workspace's activity.

python3 -c "import io,json;print([r for r in json.load(io.open('/opt/autoengine/workspaces/ferrospring.com.json'))['activity'] if r.get('kind')=='admin'])"

Only run the confirmed half if Tim is happy for a marker row to sit in his activity log.

Ledger provenance - a generator page is not an engine publish

Found on 20 Aug while writing this plan. The enquiry form on this site is marked shipped, but its own record says a site generator built it and it was back-recorded so the ledger matched reality. 47 deliverables network-wide are in that category. Counting them put the headline at 302 when the true engine figure is 255.

1. Open the deliverables list for this site.
2. For every row marked shipped, read the origin field.
3. Confirm the interface does not present a generator page as the engine's own work.

Every shipped row carries a provenance. Generator rows are visibly distinguished, and are excluded from any count of what the engine did unaided.

python3 -c "import io,json;[print(d.get('status'),'|',d.get('origin'),'|',d.get('title')) for d in json.load(io.open('/opt/autoengine/workspaces/maxelmagnets.com.json'))['deliverables']]"

This is the one most likely to embarrass us in the room, because the flattering number is the one already written down.

The two dead ends Dawn already found

Both are open on the huddle and both are the kind of thing a first-time customer hits in their first ten minutes.

1. Add a domain that is reachable and ordinary. Watch for “it doesn't look like a readable site” with no way forward.
2. Then try to remove a domain you added by mistake.

Adding works, or fails with a reason and a retry. Removing is possible at all — currently there is no path.

journalctl -u autoengine --since '10 min ago' | tail -40