docs(plugins): module catalog & the open-core line (HT-66) - #75
Merged
Conversation
The canonical free-vs-paid decision doc, from TJ's 2026-07-18 review of the FreeScout official-module inventory (71 modules, public listing — priced-demand data only, no module source observed) against the charter: - Free core = parity + hygiene: everything table-stakes, including features the reference ecosystem paywalls (tags, API/webhooks, KB, dark mode, keyboard shortcuts) and passkey login (WebAuthn) — security hygiene is always free. - Paid = three clusters: Intelligence (draft-reply assistant first; AI subsumes translator/enrichment/learning-spam-filter), Channels & integrations, Enterprise & ops (Enterprise Auth = SSO/SCIM/2FA policy/login audit — the accepted auth paywall, passkeys stay core). - Widget/portal free-with-branding; branding removal paid. - Born-proprietary discipline, zero privileged first-party access, out-of-process preferred shape; build sequence → HT-67 substrate spec. admin-ia.md §2's "decided at ticket grooming" calls resolve to this catalog (all four flagged modules land core-free); cross-referenced. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe changes add a canonical module catalog defining free and paid boundaries, module delivery contracts, and marketplace semantics. Related admin IA guidance and repository vocabulary now reference the catalog, while delegation rules clarify review ownership and escalation. ChangesCore-versus-paid module boundary
Review governance
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@specs/plugins/catalog.md`:
- Around line 20-24: Clarify the “AGPL-free in core” wording in the paragraph by
explicitly stating that these features are AGPL-licensed and available free of
charge in the core. Preserve the existing feature and paywall distinctions while
removing any implication that the functionality is not AGPL licensed.
- Around line 82-89: Update the AI terminology in the catalog section: replace
“assistant actor” and “assistant modules” with “Assistant” vocabulary, and
ensure any related API references use “Assistant” as the AI actor term. Preserve
“Agent” exclusively for human support staff and apply the same terminology
consistently in the referenced later section.
- Around line 9-14: Revise the provenance paragraph to remove claims that the
FreeScout module listing proves operators’ purchasing behavior. Replace
“priced-demand data” and “what self-hosted helpdesk operators actually pay for”
with wording limited to module inventory and market signals, while preserving
the existing source, date, and provenance constraints.
In `@specs/ui/admin-ia.md`:
- Around line 41-44: Update the “Core-vs-module” sentence in the specification
to replace the ambiguous “core-free” wording with “in the free core” or “core
and free,” while preserving the existing catalog decision and monetization
principle.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 47738cfa-9b3b-40f4-afa3-526b2143d8c4
📒 Files selected for processing (2)
specs/plugins/catalog.mdspecs/ui/admin-ia.md
Comment on lines
+9
to
+14
| **Provenance.** The market inventory below derives from FreeScout's public module listing | ||
| (freescout.net/modules — 71 official modules, read 2026-07-18) and the black-box | ||
| observations already recorded in `admin-ia.md`. It is priced-demand data: a decade of what | ||
| self-hosted helpdesk operators actually pay for. No module source code was observed | ||
| (CHARTER provenance rules). FreeScout's third-party community marketplace has not yet been | ||
| inventoried; revisit at grooming if a gap appears. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Do not describe the module listing as proof of what operators actually pay for.
The cited listing supports an inventory and market-signal claim, but it does not establish actual purchasing behavior. Please soften “priced-demand data” and “what ... operators actually pay for” unless payment evidence is available.
Suggested wording
- It is priced-demand data: a decade of what
- self-hosted helpdesk operators actually pay for.
+ It is market-signal data: a decade of modules offered to
+ self-hosted helpdesk operators.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| **Provenance.** The market inventory below derives from FreeScout's public module listing | |
| (freescout.net/modules — 71 official modules, read 2026-07-18) and the black-box | |
| observations already recorded in `admin-ia.md`. It is priced-demand data: a decade of what | |
| self-hosted helpdesk operators actually pay for. No module source code was observed | |
| (CHARTER provenance rules). FreeScout's third-party community marketplace has not yet been | |
| inventoried; revisit at grooming if a gap appears. | |
| **Provenance.** The market inventory below derives from FreeScout's public module listing | |
| (freescout.net/modules — 71 official modules, read 2026-07-18) and the black-box | |
| observations already recorded in `admin-ia.md`. It is market-signal data: a decade of modules offered to | |
| self-hosted helpdesk operators. No module source code was observed | |
| (CHARTER provenance rules). FreeScout's third-party community marketplace has not yet been | |
| inventoried; revisit at grooming if a gap appears. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@specs/plugins/catalog.md` around lines 9 - 14, Revise the provenance
paragraph to remove claims that the FreeScout module listing proves operators’
purchasing behavior. Replace “priced-demand data” and “what self-hosted helpdesk
operators actually pay for” with wording limited to module inventory and market
signals, while preserving the existing source, date, and provenance constraints.
Comment on lines
+20
to
+24
| - Everything a self-hosted helpdesk operator would call table stakes — including features | ||
| FreeScout paywalls — ships AGPL-free in core. Security hygiene is always free: | ||
| **passkey login (WebAuthn) is core**, deliberately, where the reference ecosystem sells | ||
| 2FA. The conventionally accepted auth paywall is enterprise SSO, and that is where ours | ||
| sits (§3.3). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clarify “AGPL-free” to avoid a licensing contradiction.
The same document describes the core as “charter-core AGPL” at Line [48], so “AGPL-free” can be read as “not AGPL licensed.” State explicitly that the functionality is free of charge in the AGPL core, or that it is AGPL-licensed and free of charge.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@specs/plugins/catalog.md` around lines 20 - 24, Clarify the “AGPL-free in
core” wording in the paragraph by explicitly stating that these features are
AGPL-licensed and available free of charge in the core. Preserve the existing
feature and paywall distinctions while removing any implication that the
functionality is not AGPL licensed.
Comment on lines
+82
to
+89
| - **Draft-reply assistant** — the first module (§4). Subscribes to inbound events, calls | ||
| the operator-configured model with the operator's keys, posts a draft as an assistant | ||
| actor; an Agent approves in core UI. Pure out-of-process. | ||
| - **Auto-triage** — tagging, routing, priority; same event-driven shape. | ||
| - **KB-grounded auto-answers** — depends on the KB and widget; later. | ||
| - AI subsumes rather than ports several reference modules: ticket translation, | ||
| learning spam filter, customer data enrichment, satisfaction/sentiment analysis become | ||
| facets of assistant modules, not standalone products. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use the canonical “Assistant” vocabulary for AI actors.
Terms such as “assistant actor,” “assistant modules,” and “assistant-actor API” are inconsistent with the required Agent/Assistant distinction. Use “Assistant” when referring to the AI actor, including the API terminology.
As per coding guidelines, human support staff must be referred to as “Agents” and AI actors as “Assistants.”
Also applies to: 121-128
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@specs/plugins/catalog.md` around lines 82 - 89, Update the AI terminology in
the catalog section: replace “assistant actor” and “assistant modules” with
“Assistant” vocabulary, and ensure any related API references use “Assistant” as
the AI actor term. Preserve “Agent” exclusively for human support staff and
apply the same terminology consistently in the referenced later section.
Source: Coding guidelines
Comment on lines
+41
to
+44
| features. Core-vs-module is now decided: `specs/plugins/catalog.md` (HT-66) is the | ||
| canonical line — all four land core-free there; the charter's floor ("nothing free | ||
| today gets paywalled retroactively; monetization adds, never subtracts") applies, and | ||
| AI-powered modules lead the paid catalog. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Replace the ambiguous “core-free” wording.
“Core-free” can mean excluded from core, while the catalog says these features belong in the free core. Use “in the free core” or “core and free” to make the decision unambiguous.
Suggested wording
- canonical line — all four land core-free there;
+ canonical line — all four land in the free core there;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| features. Core-vs-module is now decided: `specs/plugins/catalog.md` (HT-66) is the | |
| canonical line — all four land core-free there; the charter's floor ("nothing free | |
| today gets paywalled retroactively; monetization adds, never subtracts") applies, and | |
| AI-powered modules lead the paid catalog. | |
| features. Core-vs-module is now decided: `specs/plugins/catalog.md` (HT-66) is the | |
| canonical line — all four land in the free core there; the charter's floor ("nothing free | |
| today gets paywalled retroactively; monetization adds, never subtracts") applies, and | |
| AI-powered modules lead the paid catalog. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@specs/ui/admin-ia.md` around lines 41 - 44, Update the “Core-vs-module”
sentence in the specification to replace the ambiguous “core-free” wording with
“in the free core” or “core and free,” while preserving the existing catalog
decision and monetization principle.
…-66) Records TJ's rule that dogfood-built infrastructure is sellable without rebuild: runtime credentials vs licenses decoupled permanently (license = distribution credential, no runtime phone-home), dogfooding needs no licensing, module attribution starts in substrate v1, hosted modules are ordinary SaaS billing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…(HT-66) TJ's call, standardizing on the charter's own product noun: specs/plugins/ becomes specs/modules/, "plugin API" wording becomes "module API", and CLAUDE.md's vocabulary section pins the rule. The word "plugin" survives only in the legal phrase "plugin exception" (§7 additional permission). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…calation (TJ) Mirror sync from the canonical delegation-ladder doc: the reviewer generates findings, the lead adjudicates (that IS the sign-off); default reviewer stays one tier above the author, but sacred-invariant work escalates to a lead-tier reviewer plus a different-vendor pass — earned empirically in the substrate run (disjoint blind spots). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/rules/delegation-ladder.md:
- Around line 34-35: Add an explicit requirement to the review process
documentation for durable evidence of human review and sign-off. For
sacred-invariant changes, require a preserved PR checklist or artifact recording
the lead’s adjudication, the independent different-vendor review findings, and
human approval, alongside the existing bullets on reviewer roles and tiered
escalation.
- Line 35: Update the “Tiered review escalation” guidance to explicitly handle
lead-authored artifacts: when the lead is the author and already occupies the
highest tier, apply the same-tier parallel-review rule defined on Line 33
instead of assigning a higher-tier reviewer. Preserve the existing
one-tier-above-author rule for non-lead authors and the sacred-invariant
escalation requirements.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 8ec56805-cbcc-4325-b8f4-f3abed666b99
📒 Files selected for processing (1)
.claude/rules/delegation-ladder.md
Comment on lines
+34
to
+35
| - **Finding vs. sign-off.** The reviewer *generates adversarial findings*; the lead *adjudicates* them — judges which are real, directs the fixes, spot-checks the result. Adjudication is the sign-off, and it always happens at the lead's tier by construction. "Who reviews" is therefore a question about defect-hunting, never about who approves. | ||
| - **Tiered review escalation (TJ, 2026-07-19).** Default reviewer for contained implementation is one tier above the author (Opus for Sonnet work under a Fable lead). Work touching a repo's **sacred invariants** (e.g. mail semantics, auth/security-critical paths, the licensing boundary) escalates to a reviewer at the lead's own tier **plus** an independent different-vendor pass (e.g. Codex). Rationale, earned empirically (Helpthread substrate run, 2026-07-19): every reviewer tier caught real defects, but *different* models caught disjoint ones — a Codex pass found a TOCTOU that both a Sonnet author and an Opus review missed, and a Sonnet author found a spec bug a Fable-tier review had passed. Diversity catches what tier alone doesn't; spend tier where invariants are sacred, spend diversity everywhere it's cheap. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | 🏗️ Heavy lift
Require durable evidence of human review and sign-off.
These bullets define model-review roles but do not require human approval or preservation of the reviewer findings in git history. For sacred-invariant work such as licensing-boundary changes, add an explicit PR checklist/artifact recording the lead adjudication, different-vendor pass, and human approval.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/rules/delegation-ladder.md around lines 34 - 35, Add an explicit
requirement to the review process documentation for durable evidence of human
review and sign-off. For sacred-invariant changes, require a preserved PR
checklist or artifact recording the lead’s adjudication, the independent
different-vendor review findings, and human approval, alongside the existing
bullets on reviewer roles and tiered escalation.
Source: Learnings
|
|
||
| - **Review invariant.** Reviewer ≠ author, and reviewer tier ≥ author tier. When the lead authors an artifact itself, the reviewer is a *parallel* agent at the lead's own tier — a Fable lead gets a parallel Fable reviewer, an Opus lead a parallel Opus reviewer — so the review is independent of the author's context. | ||
| - **Finding vs. sign-off.** The reviewer *generates adversarial findings*; the lead *adjudicates* them — judges which are real, directs the fixes, spot-checks the result. Adjudication is the sign-off, and it always happens at the lead's tier by construction. "Who reviews" is therefore a question about defect-hunting, never about who approves. | ||
| - **Tiered review escalation (TJ, 2026-07-19).** Default reviewer for contained implementation is one tier above the author (Opus for Sonnet work under a Fable lead). Work touching a repo's **sacred invariants** (e.g. mail semantics, auth/security-critical paths, the licensing boundary) escalates to a reviewer at the lead's own tier **plus** an independent different-vendor pass (e.g. Codex). Rationale, earned empirically (Helpthread substrate run, 2026-07-19): every reviewer tier caught real defects, but *different* models caught disjoint ones — a Codex pass found a TOCTOU that both a Sonnet author and an Opus review missed, and a Sonnet author found a spec bug a Fable-tier review had passed. Diversity catches what tier alone doesn't; spend tier where invariants are sacred, spend diversity everywhere it's cheap. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Clarify the lead-authored exception.
“Reviewer one tier above the author” is impossible when the lead authors the artifact and already occupies the highest tier. Explicitly reference the same-tier parallel-review rule from Line 33 to prevent conflicting reviewer assignments.
Proposed clarification
-- Default reviewer for contained implementation is one tier above the author
+- Default reviewer for contained implementation is one tier above the author;
+ when the lead authors the artifact, use the same-tier parallel reviewer
+ defined by the review invariant above.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - **Tiered review escalation (TJ, 2026-07-19).** Default reviewer for contained implementation is one tier above the author (Opus for Sonnet work under a Fable lead). Work touching a repo's **sacred invariants** (e.g. mail semantics, auth/security-critical paths, the licensing boundary) escalates to a reviewer at the lead's own tier **plus** an independent different-vendor pass (e.g. Codex). Rationale, earned empirically (Helpthread substrate run, 2026-07-19): every reviewer tier caught real defects, but *different* models caught disjoint ones — a Codex pass found a TOCTOU that both a Sonnet author and an Opus review missed, and a Sonnet author found a spec bug a Fable-tier review had passed. Diversity catches what tier alone doesn't; spend tier where invariants are sacred, spend diversity everywhere it's cheap. | |
| - **Tiered review escalation (maintainer, 2026-07-19).** Default reviewer for contained implementation is one tier above the author; when the lead authors the artifact, use the same-tier parallel reviewer defined by the review invariant above. Work touching a repo's **sacred invariants** (e.g. mail semantics, auth/security-critical paths, the licensing boundary) escalates to a reviewer at the lead's own tier **plus** an independent different-vendor pass (e.g. Codex). Rationale, earned empirically (Helpthread substrate run, 2026-07-19): every reviewer tier caught real defects, but *different* models caught disjoint ones — a Codex pass found a TOCTOU that both a Sonnet author and an Opus review missed, and a Sonnet author found a spec bug a Fable-tier review had passed. Diversity catches what tier alone doesn't; spend tier where invariants are sacred, spend diversity everywhere it's cheap. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/rules/delegation-ladder.md at line 35, Update the “Tiered review
escalation” guidance to explicitly handle lead-authored artifacts: when the lead
is the author and already occupies the highest tier, apply the same-tier
parallel-review rule defined on Line 33 instead of assigning a higher-tier
reviewer. Preserve the existing one-tier-above-author rule for non-lead authors
and the sacred-invariant escalation requirements.
This was referenced Jul 19, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The canonical free-vs-paid line for Helpthread functionality (
specs/plugins/catalog.md), decided by the maintainer 2026-07-18 from an inventory of FreeScout's official module catalog (71 modules) read against the charter's §3/§4 constraints.specs/ui/admin-ia.md§2's "decided at ticket grooming" calls are resolved by this catalog (Custom Folders, Saved Replies, Send & Close, Satisfaction Ratings → core-free); cross-reference + changelog entry added there.Provenance
Derived from FreeScout's public module listing (freescout.net/modules) — priced market-demand data — plus the black-box observations already in admin-ia.md. No module source code observed (CHARTER provenance rules). Their community marketplace is not yet inventoried; noted in the doc.
Tickets
Docs-only change; no code paths touched.
🤖 Generated with Claude Code
Summary by CodeRabbit