fix: status home redirect #47
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates navigation/routing around the “Running Status” (/status) area and tightens dashboard access behavior, alongside a broad set of formatting-only changes.
Changes:
- Replace the former “Performance” navigation entry with “Running Status” and map permissions to
/status. - Add a permission-aware dashboard guard flow (fetch user policy, redirect to
/403when access is denied). - Improve config loading behavior (dedupe concurrent loads) and add signed fetching for server version info (used by a new sidebar version footer).
Reviewed changes
Copilot reviewed 203 out of 205 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
lib/console-permissions.ts |
Updates page permission mapping to use /status. |
config/navs.ts |
Changes nav label/route from Performance → Running Status (/status). |
app/(dashboard)/status/page.tsx |
Updates page header text to “Running Status”. |
hooks/use-permissions.tsx |
Adds hasFetchedPolicy and exposes policy-fetching/access checks. |
components/dashboard-auth-guard.tsx |
Enforces permission-based routing and redirects to /403. |
lib/config.ts / lib/config-helpers.ts |
Adds promise de-duplication for config loading and signed version fetch. |
components/sidebars/version.tsx / components/app-sidebar.tsx |
Adds sidebar footer version display using loaded config release info. |
i18n/locales/*.json |
Adds translations for the “Running Status” label. |
Comments suppressed due to low confidence (1)
hooks/use-permissions.tsx:87
useEffectauto-fetch condition (api && !isAdmin && !userPolicy && !isLoading) will refetch indefinitely when the account has no policy (or fetch fails and setsuserPolicyback to null). SincehasFetchedPolicyis now tracked, gate the fetch on!hasFetchedPolicy(and consider resettinghasFetchedPolicyto false whenapi/auth changes) so a successful fetch with an empty policy does not trigger an infinite request loop.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| useEffect(() => { | ||
| if (!isReady || !isAuthenticated || isAdmin) return | ||
| if (!userPolicy && !isLoading) { | ||
| void fetchUserPolicy() | ||
| } | ||
| }, [isReady, isAuthenticated, isAdmin, userPolicy, isLoading, fetchUserPolicy]) |
There was a problem hiding this comment.
This effect triggers fetchUserPolicy() whenever userPolicy is null and isLoading is false, which can cause repeated fetches (especially for users with no policy / failed fetch) and duplicates the fetch already performed in PermissionsProvider. Consider removing this effect or gating it with !hasFetchedPolicy (and relying on the provider to fetch) to avoid request loops and redundant calls.
| const credentials = getStoredSigningCredentials() | ||
| if (!credentials) { | ||
| logger.warn("Skip version config fetch: no signing credentials available") | ||
| return null | ||
| } |
There was a problem hiding this comment.
logger.warn("Skip version config fetch: no signing credentials available") will fire on any configManager.loadConfig() call before login (e.g., on the login page or first render), which can create noisy logs in normal/expected flows. Consider lowering this to debug/info, or only warning when credentials are expected (e.g., after authentication).
| 4. Detection passes: | ||
| A. Duplication detection: | ||
| - Identify near-duplicate requirements. Mark lower-quality phrasing for consolidation. | ||
| B. Ambiguity detection: | ||
| - Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria. | ||
| - Flag unresolved placeholders (TODO, TKTK, ???, <placeholder>, etc.). | ||
| C. Underspecification: | ||
| - Requirements with verbs but missing object or measurable outcome. | ||
| - User stories missing acceptance criteria alignment. | ||
| - Tasks referencing files or components not defined in spec/plan. | ||
| D. Constitution alignment: | ||
| - Any requirement or plan element conflicting with a MUST principle. | ||
| - Missing mandated sections or quality gates from constitution. | ||
| E. Coverage gaps: | ||
| - Requirements with zero associated tasks. | ||
| - Tasks with no mapped requirement/story. | ||
| - Non-functional requirements not reflected in tasks (e.g., performance, security). | ||
| F. Inconsistency: | ||
| - Terminology drift (same concept named differently across files). | ||
| - Data entities referenced in plan but absent in spec (or vice versa). | ||
| - Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note). | ||
| - Conflicting requirements (e.g., one requires to use Next.js while other says to use Vue as the framework). | ||
| - Identify near-duplicate requirements. Mark lower-quality phrasing for consolidation. | ||
| B. Ambiguity detection: | ||
| - Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria. | ||
| - Flag unresolved placeholders (TODO, TKTK, ???, <placeholder>, etc.). | ||
| C. Underspecification: | ||
| - Requirements with verbs but missing object or measurable outcome. | ||
| - User stories missing acceptance criteria alignment. | ||
| - Tasks referencing files or components not defined in spec/plan. | ||
| D. Constitution alignment: | ||
| - Any requirement or plan element conflicting with a MUST principle. | ||
| - Missing mandated sections or quality gates from constitution. | ||
| E. Coverage gaps: | ||
| - Requirements with zero associated tasks. | ||
| - Tasks with no mapped requirement/story. | ||
| - Non-functional requirements not reflected in tasks (e.g., performance, security). | ||
| F. Inconsistency: | ||
| - Terminology drift (same concept named differently across files). | ||
| - Data entities referenced in plan but absent in spec (or vice versa). | ||
| - Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note). | ||
| - Conflicting requirements (e.g., one requires to use Next.js while other says to use Vue as the framework). |
There was a problem hiding this comment.
The Markdown list formatting under "4. Detection passes" is currently mis-indented (items B–F are nested under the preceding bullet), which makes the prompt harder to read and may change how it renders in Markdown viewers. Re-indent the A–F sections and their sub-bullets consistently (similar to how other prompt files structure nested lists).
1 participant
Pull Request
Description
Type of Change
Testing
Checklist
Related Issues
Closes #
Screenshots (if applicable)
Additional Notes