Add 'make roll-call' for voluntary opt-in installation telemetry via GitHub Discussions

[sebastientaggart]

Problem to Fix

There is no way for CodeCannon users to voluntarily signal that they have installed the project. The maintainer has no visibility into where CodeCannon is being used, making it hard to gauge adoption or know which installations need updates.

Why it Matters

Without any adoption signal, the maintainer cannot prioritize work based on real usage, and users who want to support the project have no lightweight way to say "I'm here." For the maintainer personally, knowing which repos use CodeCannon means knowing where to go when a new version ships.

General Approach

Add a make roll-call target that users run voluntarily (opt-in by action, not configuration). When run, it detects the current repo, CodeCannon version, and active adapters, then posts a structured comment to a pinned GitHub Discussion on the CodeCannon repo. No config changes, no skill changes, no automatic telemetry — the act of running the command is the opt-in.

Complexity

Verification / QA effort: moderate
Requires verifying the GitHub Discussion comment is posted correctly, the gathered metadata is accurate, and edge cases (missing gh auth, no .codecannon.yaml) are handled gracefully.

Acceptance Criteria

• Running make roll-call posts a comment to the designated GitHub Discussion with repo name, CodeCannon version, active adapters, and date
• The command does nothing automatically — it only runs when a user explicitly invokes it
• The help target lists roll-call with a friendly description
• Graceful error messages if gh is not authenticated or the API call fails
• No changes to sync.py, config schema, or skill files

[sebastientaggart]

Agent Implementation Notes

Files to change

• Makefile — add roll-call target and update the help target

Approach

1. Create a GitHub Discussion (one-time, manual) in the CodeCannon repo as the collection point — category "General" or a new "Telemetry" category. This is a prerequisite, done outside of code.

2. make roll-call target in the Makefile:

   • Uses gh repo view --json nameWithOwner to get the caller's repo identity
   • Reads CodeCannon/VERSION (the submodule path) for the version — falling back to checking locally if running inside the CodeCannon repo itself
   • Parses .codecannon.yaml to detect active adapters (grep for adapter names or read the adapters: key)
   • Posts a comment to the pinned Discussion via gh api graphql (Discussions require GraphQL, not REST)
   • Comment format: 📡 owner/repo — v0.5.0 — adapters: claude, cursor — 2026-04-12
   • Prints a friendly thank-you message on success

3. GraphQL mutation for posting a Discussion comment:

   mutation {
     addDiscussionComment(input: {discussionId: "<id>", body: "..."}) {
       comment { id }
     }
   }

   The Discussion node ID will be hardcoded (it's stable once created).

4. Error handling:

   • If gh is not installed or not authenticated → clear message pointing to gh auth login
   • If the API call fails → show the error, suggest checking permissions
   • If .codecannon.yaml is missing → still post, just omit adapters

5. Help target — add a "Community" section with roll-call and a friendly description like "Say hello — let us know you're using CodeCannon"

Edge cases

• Running from inside the CodeCannon repo itself (not as a submodule) — detect via presence of VERSION in current dir vs CodeCannon/VERSION
• User has already posted — Discussion comments are append-only, duplicates are harmless but we could note "you can run this again anytime to update your version"
• Private repos — the repo name is only visible to the maintainer via the Discussion, which is on the public CodeCannon repo. Users should be aware their repo name will be public. Add a note about this before posting.

[sebastientaggart]

Resolution

Users can now run make roll-call to voluntarily post a check-in to a public GitHub Discussion, sharing their repo name, CodeCannon version, and active adapters. The command shows a preview and asks for confirmation before posting, so nothing is sent without explicit consent.

See #134 for full technical details.