docs(roadmap): record permanently-excluded, never-planned items

[jackgranatowski]

Summary

Adds a permanently excluded block under ## Out of scope in docs/roadmap.md, mirroring the framework's stance, so these deliberate architectural decisions are not re-proposed or picked up by accident:

1. A SCSS / preprocessor authoring field — no "custom SCSS" input with mixins/functions; the framework is pure CSS, configured via token overrides + a plain custom-CSS field.
2. Prefix-based automatic component styling — no auto-styling of arbitrary classes by name pattern; components are explicit BEM .sf-* classes surfaced as builder presets.
3. Viewport-breakpoint utility / mixin generation — layout adapts via container queries and breakpoint-free techniques.
4. Generating a full utility-class library — token- and primitive-first; only small opt-in helpers on demand.

Type

• fix
• feat
• docs
• chore / tooling

Checklist

• Conventional Commit messages (feat:, fix:, docs:, …)
• Docs-only change — no code, tests, or generated artifacts touched (docs/roadmap.md only)
• Generated artifacts not hand-edited (dist/, data/* untouched)
• CHANGELOG.md — n/a (internal roadmap doc, not a user-facing product change)

Notes

Documentation only. Mirrors the corresponding exclusions added to the framework roadmap so both the framework and plugin teams see the same permanent non-goals.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AR8LFdZpCqJj3AaYWM4hB4

---

Generated by Claude Code

Summary by CodeRabbit

• Documentation
  • Clarified the roadmap with an “Out of scope” section.
  • Documented several features that will not be added in future releases, including custom SCSS authoring fields, automatic class-based styling, breakpoint utility generation, and a broad utility-class library.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4e2f8410-b33b-4792-bbe8-0817fb300137

📥 Commits

Reviewing files that changed from the base of the PR and between d4be5df and 7c6751d.

📒 Files selected for processing (1)

• docs/roadmap.md

---

📝 Walkthrough

Walkthrough

This PR updates docs/roadmap.md to add an "Out of scope" section documenting four features permanently excluded from the plugin's roadmap: custom SCSS authoring field, prefix-based auto-styling, viewport breakpoint utility/mixin generation, and broad utility-class library generation.

Changes

Roadmap Documentation Update

Layer / File(s)	Summary
Document permanently excluded features docs/roadmap.md	Adds an "Out of scope" subsection listing four deliberate exclusions: no custom SCSS authoring field, no prefix-based automatic component styling, no viewport breakpoint utility/mixin generation, and no broad utility-class library.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested labels: documentation

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the roadmap docs update that records permanently excluded, never-planned items.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/roadmap-out-of-scope-distq0

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

docs(roadmap): record permanently excluded out-of-scope items

📝 Documentation 🕐 10-20 Minutes

AI Description

• Add a “permanently excluded” section under “Out of scope” in the roadmap.
• Document four explicit non-goals to prevent recurring proposals and accidental pickup.
• Align plugin roadmap exclusions with the framework’s stated architectural stance.

High-Level Assessment

The following are alternative approaches to this PR:

1. Capture non-goals as ADRs (Architecture Decision Records)

• ➕ Provides stronger historical context and rationale per decision
• ➕ Improves discoverability for architecture discussions beyond the roadmap
• ➖ More process overhead than a roadmap section
• ➖ Readers may not check ADRs when scanning scope

2. Add non-goals to CONTRIBUTING / issue templates

• ➕ Intercepts proposals at the point of submission
• ➕ Reduces maintainer load responding to repeat requests
• ➖ Non-goals become fragmented across documents
• ➖ Doesn’t help readers who only consult the roadmap

Recommendation: Keep the non-goals in the roadmap as done here (it’s the highest-visibility place for scope scanning). If these exclusions start generating debate, consider adding lightweight ADR links or a short “rationale” pointer to preserve deeper context without bloating the roadmap.

Files changed (1) +19 / -0

Documentation (1) +19 / -0

roadmap.mdAdd permanently-excluded non-goals under Out of scope +19/-0

Add permanently-excluded non-goals under Out of scope

• Introduces a “permanently excluded” block documenting four deliberate non-goals (no SCSS authoring field, no prefix-based auto styling, no breakpoint utility/mixin generation, and no full utility-class library generation). Clarifies these are architectural decisions mirroring the framework stance, not backlog items.

docs/roadmap.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 5 rules

1. Confusing .sf-* naming ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

In docs/roadmap.md, the new out-of-scope bullet says components are “explicit BEM classes
(.sf-*)”, but the repo treats the sf- prefix as a reserved namespace for SLASHED
framework/utility classes (not a general statement about BEM). This can mislead contributors about
what sf-* represents and how it relates to user-defined BEM names.

Code

docs/roadmap.md[R41-44]

+- **Prefix-based automatic component styling** — the plugin will not auto-style
+  arbitrary classes by name pattern. Components are explicit BEM classes (`.sf-*`)
+  surfaced as builder presets; there is deliberately no "style anything matching this
+  prefix" mechanism.

Relevance

⭐⭐⭐ High

Team often accepts doc-accuracy/clarification fixes to avoid confusion (accepted in PRs #111, #153).

PR-#111
PR-#153

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The roadmap text explicitly calls .sf-* “BEM classes”, while other docs and data define sf- as a
reserved SLASHED framework/utility namespace and enumerate many sf-* classes that are clearly
framework utilities (e.g., sf-grid-cols-*).

docs/roadmap.md[37-45]
docs/rebemer.md[136-146]
SLASHED-for-WP/data/inventory.json[697-740]
SLASHED-for-WP/admin-app/framework-css/badges/slashed.full.css[2834-2862]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/roadmap.md` currently says: “Components are explicit BEM classes (`.sf-*`)…”. In this repo, `sf-` is treated as a reserved prefix for SLASHED framework/utility classes, so the wording conflates the reserved namespace with “BEM component classes”.

### Issue Context
The project already documents `sf-`/`is-` as reserved prefixes and maintains an explicit `sf_classes` inventory of framework classes.

### Fix Focus Areas
- docs/roadmap.md[41-44]

### Suggested change
Replace “explicit BEM classes (`.sf-*`)” with wording that matches the convention, e.g.:
- “Components are exposed via explicit SLASHED framework classes (`.sf-*`) surfaced as builder presets …”

(Keep the intent about “no prefix-based auto-styling”, but avoid implying that `sf-*` is the project’s generic BEM namespace.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---