version: "1.0.0" name: spernakit-tester description: 'Test Spernakit and Spernakit-derived applications by running the general tester skill with Spernakit crawl gates, testing docs, dev-config preconditions, and the in-app bug-report intake bound in. Use for QA runs, regression testing, tester scenarios, role-based workflow verification, or browser-visible defect reporting on a Spernakit app.' metadata: aidd-category: spernakit-fleet aidd-contracts: tester, testing-scenarios, bug2feature spernakit-references: docs/template/TESTING.md, docs/template/STACK.md

Test a Spernakit Application

This skill is a thin wrapper around the general tester skill. tester owns the testing method: exploration, evidence capture, scripted cases, validation, and output. This file supplies the Spernakit-specific answers to the questions tester would otherwise have to discover.

Usage

spernakit-tester [app] [url] [--scope <route-prefix|workflow>] [--role <role>]
                 [--scenarios <path|id,id>]

• Zero args → infer the app from the current repository and use the general tester defaults.
• Arguments have the same meanings as tester; this wrapper only adds the bindings below.

How to run

1. Load the staged tester contract from .aidd/skills/tester/SKILL.md (or

skills/tester/SKILL.md when running inside aidd) and follow it end to end.

1. Replace its Phase 0: Discover the project's surface with the bindings below. Everything

else in tester applies unchanged.

Precondition

Confirm that the target is Spernakit or a Spernakit-derived application: package.json carries a spernakit_version field, or the repository is Spernakit itself. If it is not, stop and run tester directly instead. None of the bindings below are required to test an application, and a non-Spernakit target is not a reason to decline the work.

Bindings

Testing documentation

Read docs/template/TESTING.md in the target repository. Treat it as the current command reference when it differs from this skill or from tester.

Lifecycle

The target URL comes from the active application config.

Automated gates

Read logs/crawltest.json after a crawl. Do not run smoke:reset, supertest, or another reset-capable gate unless the user explicitly requests that broader validation.

Do not claim that the application works unless bun run smoke:qc passes.

Rate limiting

For rapid multi-role login tests, verify that the active development config sets both rateLimit.enabled and rateLimit.authEnabled to false. Prefer process-local overrides that are restored when testing ends. If none exist, preserve persistent configuration and run rate-aware tests.

Defect intake

Use the application's bug-report dialog:

• Select Bug when an existing capability behaves incorrectly.
• Select Feature Request when the required capability does not exist.
• Put the summary, expected and actual results, reproduction steps, severity, and evidence path

in the description.

• Prefix scripted findings with the test-case ID.
• Leave the optional reporter email blank unless the user requests otherwise.
• Confirm the success notification and, when possible, the corresponding backend log entry.

Spernakit stores current reports in its database. Do not write a fallback data/bugs.json file. If the dialog is unavailable or submission cannot be confirmed, preserve the finding in the final results and identify the reporting blocker.

Dance handoff

When the caller is spernakit-dance, finish the normal tester report and then return one JSON object with this exact shape. The Dance establishes the baseline before exploration and provides those identities to this run; the tester owns the post-run retrieval and handoff.

{
	"app": "<app slug>",
	"baselineReportIds": ["<app>:<numeric id>"],
	"blockers": ["<exact blocker>"],
	"pagesVisited": ["<route or named surface>"],
	"sessionReports": [{ "<complete API report row>": "<value>" }],
	"submittedReportIds": ["<app>:<numeric id>"]
}

Use empty arrays when a category has no entries. baselineReportIds and submittedReportIds are app-qualified strings; sessionReports contains complete rows from the stabilized post-test API retrieval for every post-baseline identity. Do not include credentials, tokens, cookies, or CSRF values. Outside the Dance, use the general tester output contract without this JSON appendix.