ldraney/palinks
1
0
Fork 0
Code Issues 12 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Add feature flags guide #27

Merged
ldraney merged 4 commits from docs/feature-flags-guide into main 2026-06-08 00:30:40 +00:00
Conversation 3 Commits 4 Files changed 5 +132 -6
ldraney commented 2026-06-07 17:21:33 +00:00
Owner
Copy link

Summary

  • Create docs/feature-flags.md — the single reference for how feature flags work in palinks
  • Add to README TOC
  • Pairs with updated template-issue-feature in pal-e-docs (now requires ### Feature Flag section)

Changes

  • docs/feature-flags.md: New file covering flag types (global/role-scoped/per-user), data model, resolution order, how to add a flag, naming conventions, and lifecycle
  • README.md: Added feature flags doc to TOC

Test Plan

  • Docs-only PR — no code changes
  • Mermaid diagrams render correctly

Review Checklist

  • Passed automated review-fix loop
  • No secrets committed
  • No unnecessary file changes
  • Commit messages are descriptive
  • Feature flag needed? No — docs-only change

Related Notes

  • Closes #26
  • Related to #16 — Keycloak spike (feature flag system is part of auth/roles implementation)
  • template-issue-feature — updated in pal-e-docs to require ### Feature Flag section
  • project-palinks — project page
## Summary - Create `docs/feature-flags.md` — the single reference for how feature flags work in palinks - Add to README TOC - Pairs with updated `template-issue-feature` in pal-e-docs (now requires `### Feature Flag` section) ## Changes - `docs/feature-flags.md`: New file covering flag types (global/role-scoped/per-user), data model, resolution order, how to add a flag, naming conventions, and lifecycle - `README.md`: Added feature flags doc to TOC ## Test Plan - [ ] Docs-only PR — no code changes - [ ] Mermaid diagrams render correctly ## Review Checklist - [x] Passed automated review-fix loop - [x] No secrets committed - [x] No unnecessary file changes - [x] Commit messages are descriptive - [ ] Feature flag needed? No — docs-only change ## Related Notes - Closes #26 - Related to #16 — Keycloak spike (feature flag system is part of auth/roles implementation) - `template-issue-feature` — updated in pal-e-docs to require `### Feature Flag` section - `project-palinks` — project page
Create docs/feature-flags.md covering flag types, data model,
resolution order, naming conventions, and lifecycle. This is the
reference agents read before implementing flagged features.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ldraney commented 2026-06-07 17:22:43 +00:00
Author
Owner
Copy link

PR #27 Review

DOMAIN REVIEW

Tech stack: Docs-only PR (Markdown, Mermaid diagrams, Ruby/Rails code examples). Reviewed for accuracy against existing architecture docs and Rails conventions.

Cross-reference: docs/feature-flags.md vs docs/architecture.md

  1. FEATURE_FLAGS table schema discrepancy: The PR's ER diagram adds description, created_at, and updated_at columns that do not exist in the canonical data model in docs/architecture.md (lines 114-119). The architecture doc only has id, name, enabled_globally, role_overrides. This is not wrong -- timestamps are standard Rails and description is reasonable -- but the two docs now disagree on the schema. One of them should be updated to match the other so there is a single source of truth.

  2. Three flag types: The PR documents global, role-scoped, and per-user flags. This matches docs/architecture.md lines 131-133 exactly. Consistent.

  3. role_overrides JSONB: Both docs agree on this column type and its purpose. Consistent.

  4. User preferences JSONB: Architecture.md shows USERS.preferences described as "feature flags, display settings". The PR's ER diagram labels it "per-user flag overrides". The PR label is narrower -- it omits display settings. Minor wording inconsistency but not a conflict.

  5. Resolution order: The PR documents user pref > role override > global. This is net-new content (architecture.md does not specify resolution order). The logic is sound and matches the data model. Good addition.

  6. Ruby code examples: find_or_create_by! with a block and feature_enabled?(:symbol, current_user) are idiomatic Rails. The ERB example correctly uses <%% escaping for the diff context. No issues.

  7. Admin UI reference: The PR says "Flags are managed through the settings panel (person icon, top left)." This matches the architecture doc's description of the user dashboard at line 130. Consistent.

  8. README TOC: Entry added at a reasonable position between Visibility and User Stories. Correctly formatted with relative path and description.

  9. "Current Flags" section: The disclaimer that the system is not yet implemented, with a reference to #16 (Keycloak spike), is accurate and honest. Good.

BLOCKERS

None. This is a docs-only PR with no code changes, no secrets, and no security surface.

NITS

  1. Schema drift between docs: docs/feature-flags.md shows the FEATURE_FLAGS table with description, created_at, updated_at columns that docs/architecture.md does not have. Consider updating architecture.md to match, or add a note in the feature-flags doc that it extends the base schema. Not a blocker for a docs PR, but schema should have one canonical definition.

  2. User preferences label: The PR's ER diagram labels USERS.preferences as "per-user flag overrides" while architecture.md calls it "feature flags, display settings". The architecture.md label is broader and more accurate since preferences will hold more than just flags. Consider matching the wording.

  3. Branch naming: Branch is docs/feature-flags-guide. The SOP convention is {issue-number}-{kebab-case-purpose} (e.g., 26-feature-flags-guide). The docs/ prefix style works for discoverability but does not match the documented convention.

  4. PR body template: The body uses ## Review Checklist instead of the standard ## Related header. The "Related Notes" section is present but named differently. The "Feature flag needed?" checklist item is a nice self-referential touch for a feature-flags doc.

SOP COMPLIANCE

  • Branch named after issue -- uses docs/feature-flags-guide instead of 26-feature-flags-guide
  • PR body follows template -- Summary, Changes, Test Plan, Related all present
  • Related references project slug -- references project-palinks
  • No secrets committed
  • No unnecessary file changes -- exactly 2 files, both on-topic
  • Commit messages are descriptive

PROCESS OBSERVATIONS

  • This PR establishes design documentation ahead of implementation, which is good practice. The feature-flags doc will serve as the specification when implementation begins.
  • The cross-reference to #16 (Keycloak spike) correctly positions feature flags as dependent on the auth infrastructure.
  • The schema discrepancy between this doc and architecture.md is low-risk now but should be reconciled before implementation begins to avoid confusion about which columns are canonical.
  • No DORA risk -- docs-only change with no deployment impact.

VERDICT: APPROVED

Clean docs-only PR. The content is accurate, well-structured, and consistent with the existing architecture docs. The schema discrepancy and branch naming are nits, not blockers. The resolution order documentation and lifecycle guidance are valuable additions that the codebase did not previously have.

## PR #27 Review ### DOMAIN REVIEW **Tech stack**: Docs-only PR (Markdown, Mermaid diagrams, Ruby/Rails code examples). Reviewed for accuracy against existing architecture docs and Rails conventions. **Cross-reference: docs/feature-flags.md vs docs/architecture.md** 1. **FEATURE_FLAGS table schema discrepancy**: The PR's ER diagram adds `description`, `created_at`, and `updated_at` columns that do not exist in the canonical data model in `docs/architecture.md` (lines 114-119). The architecture doc only has `id`, `name`, `enabled_globally`, `role_overrides`. This is not wrong -- timestamps are standard Rails and `description` is reasonable -- but the two docs now disagree on the schema. One of them should be updated to match the other so there is a single source of truth. 2. **Three flag types**: The PR documents global, role-scoped, and per-user flags. This matches `docs/architecture.md` lines 131-133 exactly. Consistent. 3. **role_overrides JSONB**: Both docs agree on this column type and its purpose. Consistent. 4. **User preferences JSONB**: Architecture.md shows `USERS.preferences` described as `"feature flags, display settings"`. The PR's ER diagram labels it `"per-user flag overrides"`. The PR label is narrower -- it omits display settings. Minor wording inconsistency but not a conflict. 5. **Resolution order**: The PR documents `user pref > role override > global`. This is net-new content (architecture.md does not specify resolution order). The logic is sound and matches the data model. Good addition. 6. **Ruby code examples**: `find_or_create_by!` with a block and `feature_enabled?(:symbol, current_user)` are idiomatic Rails. The ERB example correctly uses `<%%` escaping for the diff context. No issues. 7. **Admin UI reference**: The PR says "Flags are managed through the settings panel (person icon, top left)." This matches the architecture doc's description of the user dashboard at line 130. Consistent. 8. **README TOC**: Entry added at a reasonable position between Visibility and User Stories. Correctly formatted with relative path and description. 9. **"Current Flags" section**: The disclaimer that the system is not yet implemented, with a reference to #16 (Keycloak spike), is accurate and honest. Good. ### BLOCKERS None. This is a docs-only PR with no code changes, no secrets, and no security surface. ### NITS 1. **Schema drift between docs**: `docs/feature-flags.md` shows the FEATURE_FLAGS table with `description`, `created_at`, `updated_at` columns that `docs/architecture.md` does not have. Consider updating architecture.md to match, or add a note in the feature-flags doc that it extends the base schema. Not a blocker for a docs PR, but schema should have one canonical definition. 2. **User preferences label**: The PR's ER diagram labels `USERS.preferences` as `"per-user flag overrides"` while architecture.md calls it `"feature flags, display settings"`. The architecture.md label is broader and more accurate since preferences will hold more than just flags. Consider matching the wording. 3. **Branch naming**: Branch is `docs/feature-flags-guide`. The SOP convention is `{issue-number}-{kebab-case-purpose}` (e.g., `26-feature-flags-guide`). The `docs/` prefix style works for discoverability but does not match the documented convention. 4. **PR body template**: The body uses `## Review Checklist` instead of the standard `## Related` header. The "Related Notes" section is present but named differently. The "Feature flag needed?" checklist item is a nice self-referential touch for a feature-flags doc. ### SOP COMPLIANCE - [ ] Branch named after issue -- uses `docs/feature-flags-guide` instead of `26-feature-flags-guide` - [x] PR body follows template -- Summary, Changes, Test Plan, Related all present - [x] Related references project slug -- references `project-palinks` - [x] No secrets committed - [x] No unnecessary file changes -- exactly 2 files, both on-topic - [x] Commit messages are descriptive ### PROCESS OBSERVATIONS - This PR establishes design documentation ahead of implementation, which is good practice. The feature-flags doc will serve as the specification when implementation begins. - The cross-reference to #16 (Keycloak spike) correctly positions feature flags as dependent on the auth infrastructure. - The schema discrepancy between this doc and architecture.md is low-risk now but should be reconciled before implementation begins to avoid confusion about which columns are canonical. - No DORA risk -- docs-only change with no deployment impact. ### VERDICT: APPROVED Clean docs-only PR. The content is accurate, well-structured, and consistent with the existing architecture docs. The schema discrepancy and branch naming are nits, not blockers. The resolution order documentation and lifecycle guidance are valuable additions that the codebase did not previously have.
- architecture.md: Add description, created_at, updated_at columns to
  FEATURE_FLAGS ER diagram to match feature-flags.md (these are standard
  Rails columns the feature-flags doc correctly included)
- feature-flags.md: Change USERS.preferences label from "per-user flag
  overrides" to "feature flags, display settings" to match architecture.md's
  broader and more accurate description
- feature-flags.md: Change relationship label from "overridden via
  preferences" to "toggled per-user via preferences" to match architecture.md
- visibility.md: Move contact channel from Public tier to Member tier —
  architecture.md and user-stories.md US-9 both specify contact is gated
  behind auth, contradicting the previous Public listing

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ldraney commented 2026-06-07 17:57:39 +00:00
Author
Owner
Copy link

PR #27 Review

DOMAIN REVIEW

Tech stack: Documentation (Markdown, Mermaid diagrams). No application code changed. This is a docs-only PR adding a feature flags guide, updating the architecture data model diagram, adjusting visibility tier definitions, and adding a README TOC entry.

Content review of docs/feature-flags.md:

  • Flag types (global, role-scoped, per-user) are clearly defined with a table and examples.
  • Data model mermaid diagram is consistent with the updated docs/architecture.md FEATURE_FLAGS entity (both now include description, created_at, updated_at).
  • Resolution order (per-user > role > global) is well-documented with both a text block and a flowchart. This is a sound design -- more specific overrides win.
  • The "Adding a New Flag" section gives concrete Ruby code examples for registration, gating in controllers, and gating in ERB views.
  • Naming convention section is practical and clear.
  • Lifecycle section (create > roll out > stabilize > remove) establishes good hygiene against flag debt.
  • The "Current Flags" table honestly notes the system is not yet implemented and references issue #16 for tracking. This is good -- no false claims.

docs/architecture.md changes:

  • Adds description, created_at, updated_at to the FEATURE_FLAGS mermaid entity. These are sensible additions that align the architecture diagram with the feature-flags guide.

docs/visibility.md changes:

  • Moves "Contact channel (form, mailto, calendar link)" from Public tier to Member tier. This is a design decision (contact info behind auth), which is reasonable for lead-gating.

README.md changes:

  • Adds Feature Flags doc to the TOC in a logical position (after Visibility, before User Stories). Link path is correct.

BLOCKERS

None. This is a docs-only PR with no application code, no secrets, no security surface.

NITS

  1. Mermaid diagram inconsistency in visibility.md: The PR moves "Contact channel" from Public to Member in the prose (lines 39/49), but the mermaid diagram on line 23 still lists "Portfolio, case studies, contact, public demos" under Public link examples. The diagram should be updated to move "contact" to the Member subgraph for consistency. (Not blocking for a docs PR, but creates a self-contradiction in the same file.)

  2. ERB escape in feature-flags.md: The code example uses <%% (double-percent) for ERB tags in the markdown code block. This is the correct escaping for some template engines but may render oddly in plain markdown viewers. Verify it renders correctly on Forgejo.

  3. feature_enabled? helper: The doc references a feature_enabled?(flag, user) helper that does not yet exist. The "Current Flags" note at the bottom covers this, but the code examples above could benefit from a brief inline note like "# (not yet implemented)" to avoid confusion for readers who skip to a section.

SOP COMPLIANCE

  • Branch named after issue: Branch is docs/feature-flags-guide but SOP requires {issue-number}-{kebab-case-purpose} format (expected: 26-feature-flags-guide). Non-blocking for a docs PR, but deviates from convention.
  • PR body follows template: Has Summary, Changes, Test Plan, Review Checklist, Related Notes sections.
  • Closes #26 present in Related Notes.
  • Related Notes references project-palinks.
  • No secrets committed.
  • No unnecessary file changes -- all 4 files are directly related to the feature flags documentation goal.
  • Commit messages: Not visible in diff, but PR title is descriptive.

PROCESS OBSERVATIONS

  • This is a well-scoped docs-only PR. The feature flags guide establishes conventions before implementation begins, which is good engineering practice.
  • The cross-references between architecture.md and the new feature-flags.md are consistent after the data model update.
  • The visibility.md change (contact channel to member tier) is a design decision bundled with the docs PR. It is related (feature flags + visibility are intertwined), but could arguably be a separate commit for traceability. Minor observation, not blocking.

VERDICT: APPROVED

## PR #27 Review ### DOMAIN REVIEW **Tech stack**: Documentation (Markdown, Mermaid diagrams). No application code changed. This is a docs-only PR adding a feature flags guide, updating the architecture data model diagram, adjusting visibility tier definitions, and adding a README TOC entry. **Content review of `docs/feature-flags.md`**: - Flag types (global, role-scoped, per-user) are clearly defined with a table and examples. - Data model mermaid diagram is consistent with the updated `docs/architecture.md` FEATURE_FLAGS entity (both now include `description`, `created_at`, `updated_at`). - Resolution order (per-user > role > global) is well-documented with both a text block and a flowchart. This is a sound design -- more specific overrides win. - The "Adding a New Flag" section gives concrete Ruby code examples for registration, gating in controllers, and gating in ERB views. - Naming convention section is practical and clear. - Lifecycle section (create > roll out > stabilize > remove) establishes good hygiene against flag debt. - The "Current Flags" table honestly notes the system is not yet implemented and references issue #16 for tracking. This is good -- no false claims. **`docs/architecture.md` changes**: - Adds `description`, `created_at`, `updated_at` to the FEATURE_FLAGS mermaid entity. These are sensible additions that align the architecture diagram with the feature-flags guide. **`docs/visibility.md` changes**: - Moves "Contact channel (form, mailto, calendar link)" from Public tier to Member tier. This is a design decision (contact info behind auth), which is reasonable for lead-gating. **`README.md` changes**: - Adds Feature Flags doc to the TOC in a logical position (after Visibility, before User Stories). Link path is correct. ### BLOCKERS None. This is a docs-only PR with no application code, no secrets, no security surface. ### NITS 1. **Mermaid diagram inconsistency in `visibility.md`**: The PR moves "Contact channel" from Public to Member in the prose (lines 39/49), but the mermaid diagram on line 23 still lists `"Portfolio, case studies, contact, public demos"` under Public link examples. The diagram should be updated to move "contact" to the Member subgraph for consistency. (Not blocking for a docs PR, but creates a self-contradiction in the same file.) 2. **ERB escape in feature-flags.md**: The code example uses `<%%` (double-percent) for ERB tags in the markdown code block. This is the correct escaping for some template engines but may render oddly in plain markdown viewers. Verify it renders correctly on Forgejo. 3. **`feature_enabled?` helper**: The doc references a `feature_enabled?(flag, user)` helper that does not yet exist. The "Current Flags" note at the bottom covers this, but the code examples above could benefit from a brief inline note like "# (not yet implemented)" to avoid confusion for readers who skip to a section. ### SOP COMPLIANCE - [ ] Branch named after issue: Branch is `docs/feature-flags-guide` but SOP requires `{issue-number}-{kebab-case-purpose}` format (expected: `26-feature-flags-guide`). Non-blocking for a docs PR, but deviates from convention. - [x] PR body follows template: Has Summary, Changes, Test Plan, Review Checklist, Related Notes sections. - [x] `Closes #26` present in Related Notes. - [x] Related Notes references `project-palinks`. - [x] No secrets committed. - [x] No unnecessary file changes -- all 4 files are directly related to the feature flags documentation goal. - [x] Commit messages: Not visible in diff, but PR title is descriptive. ### PROCESS OBSERVATIONS - This is a well-scoped docs-only PR. The feature flags guide establishes conventions before implementation begins, which is good engineering practice. - The cross-references between architecture.md and the new feature-flags.md are consistent after the data model update. - The visibility.md change (contact channel to member tier) is a design decision bundled with the docs PR. It is related (feature flags + visibility are intertwined), but could arguably be a separate commit for traceability. Minor observation, not blocking. ### VERDICT: APPROVED
The prose was already corrected but the Mermaid diagram still listed
contact under the Public tier examples. Now diagram and prose agree
that contact channels are auth-gated (member+).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Public visitors get a contact form (no personal info exposed).
Members get direct contact info (email, calendar) after 2FA-verified
registration (email + phone via Keycloak).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ldraney commented 2026-06-08 00:28:31 +00:00
Author
Owner
Copy link

PR #27 Review

DOMAIN REVIEW

Tech stack: Documentation only (Markdown, Mermaid diagrams, ERB code examples). No executable code changes.

Files reviewed (5 files, +132/-6):

  • README.md -- TOC entry added
  • docs/architecture.md -- FEATURE_FLAGS ERD expanded with description, created_at, updated_at
  • docs/feature-flags.md -- New 121-line guide (flag types, data model, resolution order, how-to, naming, lifecycle)
  • docs/user-stories.md -- US-9 contact channel acceptance criteria refined
  • docs/visibility.md -- Mermaid diagram and tier definitions updated for contact form/info distinction

Documentation quality:

  • Feature flags guide is well-structured with clear sections covering the full lifecycle
  • Mermaid diagrams are correct and illustrate the resolution order and data model clearly
  • Code examples (Ruby seed, controller gate, ERB template) are idiomatic and useful as implementation reference
  • The ERD in architecture.md now matches the ERD in feature-flags.md -- good consistency
  • The "Current Flags" section honestly declares the system is not yet implemented, with a forward reference to #16
  • Resolution order (per-user > role > global) is a sensible design and clearly documented

Cross-document consistency:

  • visibility.md and user-stories.md changes refine the contact channel story (US-9) -- public gets an anonymous form, members get direct contact info after 2FA. This is coherent with the feature-flag gating model
  • The architecture ERD, feature-flags ERD, and visibility model all align on the same FEATURE_FLAGS schema

BLOCKERS

None. This is a docs-only PR with no executable code changes, no secrets, and no security surface.

NITS

  1. Branch naming convention: Branch is docs/feature-flags-guide but SOP expects {issue-number}-{kebab-case} (e.g., 26-feature-flags-guide). Non-blocking for a docs PR but worth noting for consistency.

  2. Related Notes missing plan slug: The Related Notes section references project-palinks but does not reference a plan slug. If a plan note exists for this work, it should be linked.

  3. Scope creep (minor): The user-stories.md and visibility.md changes refine US-9 (contact channel) specifics beyond what a "feature flags guide" ticket would strictly cover. The changes are coherent and improve the docs, but they are tangential to the stated issue scope. Not blocking since all changes are documentation and internally consistent.

  4. ERB escape in code example: docs/feature-flags.md line 85 uses <%% which is the correct way to display ERB tags in a Markdown code fence, but the double-percent will render literally in Markdown viewers (not as <%). Consider using single <% inside the fenced code block since Markdown renderers do not process ERB. This is cosmetic only.

SOP COMPLIANCE

  • Branch named after issue (docs/feature-flags-guide vs expected 26-feature-flags-guide)
  • PR body follows template (Summary, Changes, Test Plan, Review Checklist, Related Notes)
  • Related Notes references plan slug (references project-palinks but no plan slug)
  • Closes #26 present in PR body
  • No secrets committed
  • No unnecessary file changes (minor scope expansion but all coherent)
  • Commit messages are descriptive

PROCESS OBSERVATIONS

  • Docs-only PR with zero deployment risk. No change failure risk.
  • The feature flags guide establishes a clear contract for future implementation tickets -- this should reduce ambiguity and rework when the flag system is built.
  • Cross-referencing #16 (Keycloak spike) as the implementation vehicle is good traceability.

VERDICT: APPROVED

## PR #27 Review ### DOMAIN REVIEW **Tech stack**: Documentation only (Markdown, Mermaid diagrams, ERB code examples). No executable code changes. **Files reviewed** (5 files, +132/-6): - `README.md` -- TOC entry added - `docs/architecture.md` -- FEATURE_FLAGS ERD expanded with `description`, `created_at`, `updated_at` - `docs/feature-flags.md` -- New 121-line guide (flag types, data model, resolution order, how-to, naming, lifecycle) - `docs/user-stories.md` -- US-9 contact channel acceptance criteria refined - `docs/visibility.md` -- Mermaid diagram and tier definitions updated for contact form/info distinction **Documentation quality**: - Feature flags guide is well-structured with clear sections covering the full lifecycle - Mermaid diagrams are correct and illustrate the resolution order and data model clearly - Code examples (Ruby seed, controller gate, ERB template) are idiomatic and useful as implementation reference - The ERD in `architecture.md` now matches the ERD in `feature-flags.md` -- good consistency - The "Current Flags" section honestly declares the system is not yet implemented, with a forward reference to #16 - Resolution order (per-user > role > global) is a sensible design and clearly documented **Cross-document consistency**: - `visibility.md` and `user-stories.md` changes refine the contact channel story (US-9) -- public gets an anonymous form, members get direct contact info after 2FA. This is coherent with the feature-flag gating model - The architecture ERD, feature-flags ERD, and visibility model all align on the same FEATURE_FLAGS schema ### BLOCKERS None. This is a docs-only PR with no executable code changes, no secrets, and no security surface. ### NITS 1. **Branch naming convention**: Branch is `docs/feature-flags-guide` but SOP expects `{issue-number}-{kebab-case}` (e.g., `26-feature-flags-guide`). Non-blocking for a docs PR but worth noting for consistency. 2. **Related Notes missing plan slug**: The Related Notes section references `project-palinks` but does not reference a plan slug. If a plan note exists for this work, it should be linked. 3. **Scope creep (minor)**: The `user-stories.md` and `visibility.md` changes refine US-9 (contact channel) specifics beyond what a "feature flags guide" ticket would strictly cover. The changes are coherent and improve the docs, but they are tangential to the stated issue scope. Not blocking since all changes are documentation and internally consistent. 4. **ERB escape in code example**: `docs/feature-flags.md` line 85 uses `<%%` which is the correct way to display ERB tags in a Markdown code fence, but the double-percent will render literally in Markdown viewers (not as `<%`). Consider using single `<%` inside the fenced code block since Markdown renderers do not process ERB. This is cosmetic only. ### SOP COMPLIANCE - [ ] Branch named after issue (`docs/feature-flags-guide` vs expected `26-feature-flags-guide`) - [x] PR body follows template (Summary, Changes, Test Plan, Review Checklist, Related Notes) - [ ] Related Notes references plan slug (references `project-palinks` but no plan slug) - [x] `Closes #26` present in PR body - [x] No secrets committed - [x] No unnecessary file changes (minor scope expansion but all coherent) - [x] Commit messages are descriptive ### PROCESS OBSERVATIONS - Docs-only PR with zero deployment risk. No change failure risk. - The feature flags guide establishes a clear contract for future implementation tickets -- this should reduce ambiguity and rework when the flag system is built. - Cross-referencing #16 (Keycloak spike) as the implementation vehicle is good traceability. ### VERDICT: APPROVED
ldraney deleted branch docs/feature-flags-guide 2026-06-08 00:30:40 +00:00
ldraney referenced this pull request from a commit 2026-06-08 00:30:42 +00:00
Add feature flags guide (#27)
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ldraney/palinks!27
No description provided.