Skip to content

docs(#148): correct privacy-gate wording — adopter action, not framework auto-publish#149

Merged
atlas-apex merged 1 commit into
me2resh:devfrom
atlas-apex:docs/GH-148-privacy-gate-wording-fix
May 3, 2026
Merged

docs(#148): correct privacy-gate wording — adopter action, not framework auto-publish#149
atlas-apex merged 1 commit into
me2resh:devfrom
atlas-apex:docs/GH-148-privacy-gate-wording-fix

Conversation

@atlas-apex

Copy link
Copy Markdown
Collaborator

Summary

Correct the privacy-gate wording introduced in #144 (and unchanged through #147) — it currently attributes fork publication to the framework rather than the adopter:

the standard fork-and-commit setup will silently publish your private project names on a public GitHub repo

That's factually wrong. ApexYard never pushes anything without explicit operator approval — the publication only happens when the adopter themselves runs git push. The "silently publish" framing reads as if the framework auto-publishes, which is misleading and undermines trust in the rest of the framework's safety claims.

Two prose-only edits, no code, no behavior change.

What changes

.claude/skills/setup/SKILL.md Step 2a privacy-gate question

-Why I'm asking: GitHub Free disallows changing a fork's visibility, so
-the standard fork-and-commit setup will silently publish your private
-project names on a public GitHub repo. If any project is private, I'll
-walk you through the split-portfolio mode (a separate private repo for
-the registry, public fork stays slim).
+Why I'm asking: GitHub Free disallows changing a fork's visibility, so
+under the standard fork-and-commit setup you might accidentally publish
+your private project names on a public GitHub repo (a stray `git push`
+after registering them — I won't push without your approval, but the
+risk is on the adopter once the data is committed locally). If any
+project is private, I'll walk you through the split-portfolio mode (a
+separate private repo for the registry, public fork stays slim).

docs/multi-project.md trip-wire callout

-Combined with the framework's default of committing the registry to the fork, free-tier adopters with any private project silently publish their portfolio names the moment they push.
+Combined with the framework's default of committing the registry to the fork, free-tier adopters with any private project risk accidentally publishing their portfolio names with a stray push (the framework itself never pushes without operator approval, but once the registry is committed locally the next push exposes it).

Why now

Caught by an actual adopter reviewing the just-merged #147 wording. Trust-language matters more in privacy-related UX than anywhere else — adopters need to know exactly what the framework will and won't do automatically.

Targets dev per the apexyard release-cut model.

Testing

  • grep -r "silently publish" .claude/skills/ docs/ → zero hits (verified locally).
  • markdownlint passes (no fence / table / list changes — pure prose edit).
  • lychee passes (no link changes).
  • /setup Step 2a re-read: the new wording remains conversational, doesn't lecture, and explicitly states the framework's non-push contract.
  • docs/multi-project.md trip-wire callout still flows naturally inside the surrounding paragraph.

Glossary

Term Definition
Privacy gate Step 2a in /setup (introduced #144) that asks the adopter whether any of their projects are private + branches the configuration flow on the answer.
Trip-wire The phrase used in docs/multi-project.md for the GitHub-Free-fork-visibility constraint that exposes private project names when an adopter pushes a registry commit.
Adopter-action language Phrasing that attributes a consequence to an action the adopter takes (e.g. "you might accidentally publish") rather than to the framework (e.g. "the framework will publish"). The framework only does what the adopter approves; the wording should reflect that.

Closes #148

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants