@jelias/kody-release-tracker

Install and verify a fork

Follow README setup for configuration and tracker checks. For platform fork/publish mechanics, load Kody MCP search({ entity: "guide:package_lifecycle" }); for package requirements, load search({ entity: "guide:package_authoring" }).

Before publishing

Agree on the hook action, email preference, schedule, and timezone. Use the returned fork identity for all calls. Keep a new job disabled; for an existing fork, record its enabled state and pause it with jobUpdate. Confirm it is disabled—manifest enabled: false does not pause an active job. Save the chosen schedule and timezone in package.json#kody.jobs, keeping enabled: false in the distributable manifest. Run package checks before publishing the adapted source.

Verify the hook

The README dry run checks release access; the first live run only establishes a baseline. Neither proves that your customized hook works.

• Test the actual hook with a representative release, an obvious test ID, and mocked external services.
• Repeat the ID to check duplicate handling, and exercise a service failure to check error handling.
• If live verification is needed, agree on a bounded action and inspect its destination afterward. A private fork can temporarily export the hook for this check; remove the export and republish afterward.

Fixture calls bypass the cursor. Avoid real pending release IDs for destructive tests.

Before activation

Confirm the final published revision matches the reviewed source. Run the README tracker checks against that revision, and check saved settings and cursor. With an existing baseline, review pending effects before invoking the live wrapper. Keep the job paused if verification fails. Before completing setup, confirm the published manifest and live job both match the user's chosen schedule and timezone. A jobUpdate change alone is temporary: publishing reapplies the manifest. If they differ, correct the manifest and repeat publication and verification while the job stays paused.

Enable a verified new job separately with jobUpdate, or restore an existing job's prior enabled state. Report the action, digest choice, and verified active schedule to the user.