mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-10-30 16:47:01 +09:00
Juan DenisandClaude Opus 5
d3f32bf4c2
Plan 55 tasks 6 and 7, UI half — one Permissions dialog per installed extension, following the existing config-dialog pattern on the same page. The design problem here is entirely about not overclaiming, so the three permission states render as three separate sentences rather than one vague row shared by all of them. A capability the SDK actually mediates and has seen used says so with a count. One it mediates and has NOT seen says the gate recorded nothing and names both readings — not needed yet, or declared more than it uses. One it cannot mediate renders no count, no zero, and no "unused" badge at all: it says the panel exposes no gated helper, that an extension wanting it imports the host module directly, and that the question cannot be answered here. Refused calls get their own section under their own heading rather than sitting among the declared rows, because a blocked attempt did not run and must never be mistaken for a use. Where a non-observable capability does carry gate-recorded calls — a plugin can call require() voluntarily — the count is labelled a floor rather than a total. Two caveats are stated once rather than implied: observations live in memory in one backend process and are cleared on restart, and declared permissions are a consent signal rather than a sandbox, since extension code runs inside the panel process with the panel's privileges. The requirements section names the env var from the API response rather than a hardcoded literal, distinguishes "not installed" from "installed at install time", and covers the case where the opt-in was switched on after the file was written — the panel only installs during install or update, so it says to reinstall. There is deliberately no install button; the surface is read-only and says so. Timestamps are pinned to UTC before formatting: the backend stamps them with datetime.utcnow().isoformat() and no zone suffix, which JS would otherwise read as local time and skew every relative label by the browser's offset. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
React Dashboard Template
A modern React dashboard application boilerplate built with Vite, featuring routing, charts, and a sidebar layout for building data-driven web interfaces.
Features
- React 18 with functional components and hooks
- Vite for fast development and building
- React Router for client-side routing
- Recharts for data visualization
- Lucide React for icons
- ESLint for code linting
- Responsive sidebar layout
- Dashboard page with sample components
Getting Started
Prerequisites
- Node.js 16+ and npm
Installation
- Clone or download this template
- Install dependencies:
npm install
Development
Start the development server:
npm run dev
The app will be available at http://localhost:41921.
Building for Production
Build the app for deployment:
npm run build
The output will be in the dist/ directory.
Preview Production Build
npm run preview
Project Structure
src/
├── App.jsx # Main app with routing
├── main.jsx # Entry point
├── index.css # Global styles
├── components/
│ └── Sidebar.jsx # Navigation sidebar
├── layouts/
│ └── DashboardLayout.jsx # Main layout wrapper
└── pages/
└── Dashboard.jsx # Main dashboard page
Customization
- Modify components in
src/components/ - Add new pages in
src/pages/ - Update routes in
App.jsx - Customize styles in
index.cssor component files
Environment Variables
Create a .env file in the root for environment variables:
VITE_API_URL=https://api.example.com
Access them in code via import.meta.env.VITE_API_URL.
Contributing
See the documentation files for AI agent permissions and guidelines.