fix: explicit guards against base64 README encoding and private repo creation

- Step 1: create_repo must always set private: false + auto_init: false
- Step 5: create_or_update_file content must be plain text — MCP handles
  base64 internally; pre-encoding causes double-encoding (corrupted README)

Fixes intermittent bugs observed in CW-007 (display-catalog) and CW-013
(mpm-url-shortener) where READMEs were stored as base64 blobs and repos
were created private.
This commit is contained in:
2026-05-18 19:45:48 -05:00
parent ba8a90c4df
commit 53a6a49887
@@ -23,6 +23,7 @@ Ask the user (skip anything already known from context):
If no repo exists, ask: *"Would you like me to create a new Git repo for this project?"*
If yes, use the Gitea MCP `create_repo` tool to create it now under the appropriate owner.
Name it using the project slug (lowercase, hyphenated). Record the URL.
**ALWAYS set `private: false` and `auto_init: false` when calling `create_repo`.** All CoWork repos are public. Never omit these parameters — Gitea defaults to private and will silently create a private repo if the parameter is absent.
If both a repo URL and a .plugin file are provided:
- Check the version in both `.claude-plugin/plugin.json` files
@@ -168,6 +169,7 @@ Use `create_drive_file` with:
**Push README.md to Git repo (if repo exists):**
- Use `get_file_contents` (owner, repo, ref=main, filePath=README.md) to get existing SHA
- Use `create_or_update_file` with the SHA to update, or omit SHA to create fresh
- **`content` parameter: pass the plain markdown text string directly — do NOT base64-encode it first. The Gitea MCP tool handles base64 encoding internally before sending to the API. If you pre-encode the content, it gets double-encoded and Gitea stores a base64 blob instead of readable markdown. This is a known failure mode that has caused corrupted READMEs.**
- Commit message: `docs: update README to v[version]`
Both destinations are required. Confirm both are written before proceeding.