Fix feedkit release workflow

Let me check the workflow runs for feedkit and also look at the current state of the feedkit repo more closely.

The "Create Release" step failed. The issue is that the release workflow uses softprops/action-gh-release@v2 which tries to create a release, but there's no tag specified. Let me look at the release workflow more carefully and also check what other repos do for their release workflows. Let me look at a working example from another repo.

Now I understand the issue. The feedkit release workflow was triggered via workflow_dispatch (manually), not on tag push. The logkit release workflow triggers on tag push (on: push: tags: ['v*']) and reads the version from the VERSION file. The feedkit release workflow also triggers on tag push but was manually dispatched, which means there's no tag context — the softprops/action-gh-release@v2 step doesn't know what tag to create a release for.

The key difference: logkit's release workflow reads the version from the VERSION file and passes tag_name explicitly to the release action. The feedkit release workflow doesn't pass tag_name — it relies on the git tag being present (which happens on tag push events, not workflow_dispatch).

Let me now clone the feedkit repo and fix the release workflow to match the logkit pattern. I also need to check if there are other repos with similar issues.

Good. The tag v0.1.0 exists. The problem is clear:

1. The release workflow was triggered via workflow_dispatch (manual), not via tag push
2. When triggered via workflow_dispatch, there's no GITHUB_REF pointing to a tag, so softprops/action-gh-release@v2 doesn't know what tag to use
3. The logkit release workflow handles this by reading the VERSION file and passing tag_name explicitly

I need to fix the feedkit release workflow to:

1. Read the version from the VERSION file (like logkit does)
2. Pass tag_name explicitly to the release action
3. Remove the workflow_dispatch trigger since the tag-release workflow already handles triggering the release workflow on tag push

Let me also check the other repos that might have similar issues. Let me look at the repos that were recently created and check their workflow statuses.

**************************************************************************************************************************************************************************************ce.

Now I see the key difference. The metricskit release workflow:

1. Reads the version from the VERSION file
2. Passes tag_name: ${{ steps.version.outputs.version }} to the release action

But the feedkit release workflow doesn't read the version or pass tag_name. That's why it fails when triggered via workflow_dispatch — there's no tag context.

Let me also check the metricskit release — it succeeded but the tag_name would be 0.1.0 (without the v prefix). Let me check:

I notice the metricskit release has tag_name: "0.1.0" (without the v prefix) while the tag-release workflow creates tags with the v prefix (v0.1.0). This is a minor inconsistency but it works because softprops/action-gh-release@v2 creates the tag if it doesn't exist. But ideally the tag_name should include the v prefix to match the git tag.

Now let me fix the feedkit release workflow. I'll model it after the logkit pattern (which is the most robust) — reading the VERSION file and prefixing with v.

Now let me also check the other repos for similar issues. Let me check the repos that haven't had releases yet and look at their workflow statuses.

******************************************************************************************************************************************************************ix.

*************************************************************************************************************ks.

*********************************************************************te.

Still failing. Let me check which job failed.

The "Build & Release (windows, amd64)" job failed at the "Build" step. The issue is with the tar command for Windows. The build step creates dist/feedkit.exe but the tar command tries to tar feedkit${ext} which would be feedkit.exe — but we're in the dist directory. Let me check the build step more carefully.

The build step is:

For Windows, ext=".exe", so the binary is dist/feedkit.exe (because -o dist/feedkit with GOOS=windows appends .exe automatically). Then cd dist && tar -czf feedkit-windows-amd64.tar.gz feedkit.exe — but wait, Go doesn't automatically append .exe when you specify -o dist/feedkit. Let me check.

Actually, Go DOES automatically append .exe when GOOS=windows, even with -o. So the output file is dist/feedkit.exe, and then cd dist && tar -czf ... feedkit.exe should work. But wait — the -o flag specifies the exact output name. Let me verify.

Actually, when you use -o, Go does NOT append .exe — you get exactly what you specify. So the output is dist/feedkit (no .exe), but then the tar command tries to archive feedkit.exe which doesn't exist!

The fix: either add ${ext} to the -o flag, or use feedkit (without ext) in the tar command. Let me fix this.

Now let me trigger the release workflow again.

*****************************************************************************************ed.

The release v0.1.0 is now published with all 6 assets (5 platform binaries + checksums.txt). The feedkit release workflow is now fully working.

Now let me also check the deploy-pages workflow status and see if there are any other issues across the org. Let me also check the CI workflow that was triggered by the push.

CI passed. Now let me also check the tag-release workflow status.

All workflows are passing. Now let me update the progress website. Let me read the current state of the progress files.

Now let me update the progress.json with the new entry and update the lastUpdated timestamp.

Now add the new log entry at the top of the log array.

*************************************************************************ng.

The issue is with the unicode escape. Let me use a different approach — write the content directly with a script.

****************************************************************************************ed.

Now add the new log entry to the index.html. Let me find the exact location.

The unicode escape is the issue. Let me use a Python script to update the HTML file too.

Let me verify the entry was inserted correctly.

Let me verify the JSON is valid.

Both files are valid. The progress website has been updated with the new log entry.

Let me do a final summary of what was accomplished:

1. Fixed feedkit release workflow — two issues found and resolved:

   • Issue 1: Missing tag_name — The Create Release step used softprops/action-gh-release@v2 without specifying tag_name. When triggered via workflow_dispatch (not tag push), there was no tag context, so the action failed. Fixed by reading the VERSION file and passing tag_name explicitly with v prefix.
   • Issue 2: Windows build failure — Go does not auto-append .exe when using -o with GOOS=windows. The build output was dist/feedkit but the tar command tried to archive dist/feedkit.exe which didn't exist. Fixed by explicitly including ${ext} in the -o flag.
   • Also added merge-multiple: true for artifacts, top-level permissions: contents: write, and simplified the matrix to use goos/goarch arrays with exclude for windows/arm64.

2. Verified the fix — Triggered the release workflow via workflow_dispatch, which completed successfully. Release v0.1.0 is now published with all 5 platform binaries (linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, windows/amd64) plus checksums.txt.

3. Updated progress website — Added new log entry to both progress.json and index.html, updated lastUpdated and lastActive timestamps.