[weboko]

Why

Installing a Basecamp module runs a stranger's native code with the user's full account privileges, and today nothing ties the build we evaluate to the build users install later. Releases, tags and catalog indexes are mutable and owned by the participant, updates from a different key (or unsigned) install with only a warning, and λPrize counts adoption before anyone has looked at the code. These changes ask submitters to close the part of that gap that is in their hands.

What changes for submitters

New README policy, Release integrity and security, referenced by tier from every prize:

• Signed packages with lgx sign, signer DID in trustedSigners, and the DID declared up front in the solution PR.
• Persistent (immutable) GitHub releases, with links to GitHub's official instructions (Preventing changes to your releases).
• Freeze rule: the award is for the evaluated rootHash. Never replace assets, ship changes as new versions.
• Release integrity manifest in the solution PR: commit SHA, catalog URL, package/version, release URL, rootHash, SHA-256, variants, signer DID.
• Canonical install instructions (catalog URL + DID + rootHash, never "search for X" or "disable warnings").
• Catalog on a GitHub organisation (against repojacking), optional Logos Storage CID.
• Account hygiene: 2FA, protected branches and tags, SHA-pinned Actions, signing key never exposed to PR workflows.
• Secure dev basics and safe-to-evaluate deliverables (no --accept-flake-config, no extra substituters, no prompt injection aimed at review agents).
• Security tiers 0/1/2. Tier 2 (keys/funds, wallets, AI agents) adds a threat model, approval enforced in the core module, no plaintext keys, spend caps outside the agent, and an independent review window before adoption counts.
• Adoption counts only from signed releases in the declared catalog. Third-party apps pin the signer DID or rootHash.
• Post-award obligations: signed releases only, no replaced assets, 72-hour incident notice.
• Wording: results read as "evaluated rootHash X on date Y against criteria Z", plus "Logos never DMs install links".

Files

• README.md: the policy above, and a pointer from "Submitting a Solution" and "Evaluation Policies".
• prizes/LP-0000.md: Security Tier line, plus Supportability, Adoption, Prize Structure, Submission Requirements and Evaluation Process references.
• solutions/LP-0000.md: ## Release Integrity section (manifest table), install instructions, security checklist.
• .github/scripts/validate-submission.sh + workflow: non-blocking warnings for a missing section, commit SHA, DID, rootHash or catalog URL, and a read-only GitHub API lookup that reports whether each listed release is immutable. All submitter-supplied strings are matched against strict patterns before reaching the API. GH_TOKEN is now passed to the validation step for that lookup.
• AGENTS.md: set the tier and avoid "approved/verified/safe" wording.

Existing prize files (LP-0001, 0018, 0021, 0022, 0023, 0026) are not touched.

Testing

Ran validate-submission.sh locally against a filled-in and an empty solution: the immutable lookup reports cli/cli@v2.104.0 as immutable, unreadable releases warn, and placeholders trigger every manifest warning. bash -n and git diff --check pass.

Decisions needed before merging

1. Scope in time. The policy applies to "every prize that ships a Basecamp module". Should it also apply to prizes that are open now, or only to prizes published or revised after merge (possibly with a grace date)?
2. Held-back payment. The template now has a Post-award obligations field and says a prize may hold back part of its amount. The percentage (proposal: 15 to 25%) and the period need a team and legal decision, and TERMS.md probably needs a matching clause. I did not edit TERMS.md.
3. Tier 2 vs. "release early". Tier 2 delays adoption counting until an independent review or bounty window completes. That conflicts with the "release early and start accruing adoption" advice in LP-0023-style prizes.
4. Rolling index release vs. immutability. logos-modules-release-action's rebuild-index replaces index.json in place on the index release. Per GitHub, immutability applies only to releases published after it is enabled, so creating the index release first should keep it working. This needs a quick end-to-end test on a fork, and ideally native support in the action.
5. logos-modules-release-base pins @v1/@v4. Submitters are asked to SHA-pin them. Fixing the base template upstream (R&D item) would remove that friction.
6. When to make CI blocking. The checks are warnings for now.

🤖 Generated with Claude Code

[github-actions]

❌ Validation failed

Fix before review:

• ❌ Wrong title. Rename to Solution: LP-0000 <description>.
• ❌ Solution PRs must only touch solutions/. Outside files: .github/scripts/validate-submission.sh .github/workflows/validate-submission.yml AGENTS.md README.md prizes/LP-0000.md.
• ❌ Repo link is still a placeholder.
• ❌ "Submitted by" is still a placeholder.

Warnings (non-blocking):

• ⚠️ Unfilled placeholders: LP-XXXX <Short Description>.
• ⚠️ No criteria marked met ([x]).
• ⚠️ ### Functionality: only template prompt text. Fill in your assessment.
• ⚠️ ### Usability: only template prompt text. Fill in your assessment.
• ⚠️ ### Reliability: only template prompt text. Fill in your assessment.
• ⚠️ ### Performance: only template prompt text. Fill in your assessment.
• ⚠️ ### Supportability: only template prompt text. Fill in your assessment.
• ⚠️ A solution for LP-0000 already exists on base.

---

Automated check. See solution template and TERMS.