devstack 0.1.0

package/vendor/skills/skills/interface-design/references/principles.md

@@ -0,0 +1,235 @@
+# Core Craft Principles
+
+These apply regardless of design direction. This is the quality floor.
+
+---
+
+## Surface & Token Architecture
+
+Professional interfaces don't pick colors randomly — they build systems. Understanding this architecture is the difference between "looks okay" and "feels like a real product."
+
+### The Primitive Foundation
+
+Every color in your interface should trace back to a small set of primitives:
+
+- **Foreground** — text colors (primary, secondary, muted)
+- **Background** — surface colors (base, elevated, overlay)
+- **Border** — edge colors (default, subtle, strong)
+- **Brand** — your primary accent
+- **Semantic** — functional colors (destructive, warning, success)
+
+Don't invent new colors. Map everything to these primitives.
+
+### Surface Elevation Hierarchy
+
+Surfaces stack. A dropdown sits above a card which sits above the page. Build a numbered system:
+
+```
+Level 0: Base background (the app canvas)
+Level 1: Cards, panels (same visual plane as base)
+Level 2: Dropdowns, popovers (floating above)
+Level 3: Nested dropdowns, stacked overlays
+Level 4: Highest elevation (rare)
+```
+
+In dark mode, higher elevation = slightly lighter. In light mode, higher elevation = slightly lighter or uses shadow. The principle: **elevated surfaces need visual distinction from what's beneath them.**
+
+### The Subtlety Principle
+
+This is where most interfaces fail. Study Vercel, Supabase, Linear — their surfaces are **barely different** but still distinguishable. Their borders are **light but not invisible**.
+
+**For surfaces:** The difference between elevation levels should be subtle — a few percentage points of lightness, not dramatic jumps. In dark mode, surface-100 might be 7% lighter than base, surface-200 might be 9%, surface-300 might be 12%. You can barely see it, but you feel it.
+
+**For borders:** Borders should define regions without demanding attention. Use low opacity (0.05-0.12 alpha for dark mode, slightly higher for light). The border should disappear when you're not looking for it, but be findable when you need to understand the structure.
+
+**The test:** Squint at your interface. You should still perceive the hierarchy — what's above what, where regions begin and end. But no single border or surface should jump out at you. If borders are the first thing you notice, they're too strong. If you can't find where one region ends and another begins, they're too subtle.
+
+**Common AI mistakes to avoid:**
+
+- Borders that are too visible (1px solid gray instead of subtle rgba)
+- Surface jumps that are too dramatic (going from dark to light instead of dark to slightly-less-dark)
+- Using different hues for different surfaces (gray card on blue background)
+- Harsh dividers where subtle borders would do
+
+### Text Hierarchy via Tokens
+
+Don't just have "text" and "gray text." Build four levels:
+
+- **Primary** — default text, highest contrast
+- **Secondary** — supporting text, slightly muted
+- **Tertiary** — metadata, timestamps, less important
+- **Muted** — disabled, placeholder, lowest contrast
+
+Use all four consistently. If you're only using two, your hierarchy is too flat.
+
+### Border Progression
+
+Borders aren't binary. Build a scale:
+
+- **Default** — standard borders
+- **Subtle/Muted** — softer separation
+- **Strong** — emphasis, hover states
+- **Stronger** — maximum emphasis, focus rings
+
+Match border intensity to the importance of the boundary.
+
+### Dedicated Control Tokens
+
+Form controls (inputs, checkboxes, selects) have specific needs. Don't just reuse surface tokens — create dedicated ones:
+
+- **Control background** — often different from surface backgrounds
+- **Control border** — needs to feel interactive
+- **Control focus** — clear focus indication
+
+This separation lets you tune controls independently from layout surfaces.
+
+### Context-Aware Bases
+
+Different areas of your app might need different base surfaces:
+
+- **Marketing pages** — might use darker/richer backgrounds
+- **Dashboard/app** — might use neutral working backgrounds
+- **Sidebar** — might differ from main canvas
+
+The surface hierarchy works the same way — it just starts from a different base.
+
+### Alternative Backgrounds for Depth
+
+Beyond shadows, use contrasting backgrounds to create depth. An "alternative" or "inset" background makes content feel recessed. Useful for:
+
+- Empty states in data grids
+- Code blocks
+- Inset panels
+- Visual grouping without borders
+
+---
+
+## Spacing System
+
+Pick a base unit (4px and 8px are common) and use multiples throughout. The specific number matters less than consistency — every spacing value should be explainable as "X times the base unit."
+
+Build a scale for different contexts:
+
+- Micro spacing (icon gaps, tight element pairs)
+- Component spacing (within buttons, inputs, cards)
+- Section spacing (between related groups)
+- Major separation (between distinct sections)
+
+## Symmetrical Padding
+
+TLBR must match. If top padding is 16px, left/bottom/right must also be 16px. Exception: when content naturally creates visual balance.
+
+```css
+/* Good */
+padding: 16px;
+padding: 12px 16px; /* Only when horizontal needs more room */
+
+/* Bad */
+padding: 24px 16px 12px 16px;
+```
+
+## Border Radius Consistency
+
+Sharper corners feel technical, rounder corners feel friendly. Pick a scale that fits your product's personality and use it consistently.
+
+The key is having a system: small radius for inputs and buttons, medium for cards, large for modals or containers. Don't mix sharp and soft randomly — inconsistent radius is as jarring as inconsistent spacing.
+
+## Depth & Elevation Strategy
+
+Match your depth approach to your design direction. Choose ONE and commit:
+
+**Borders-only (flat)** — Clean, technical, dense. Works for utility-focused tools where information density matters more than visual lift. Linear, Raycast, and many developer tools use almost no shadows — just subtle borders to define regions.
+
+**Subtle single shadows** — Soft lift without complexity. A simple `0 1px 3px rgba(0,0,0,0.08)` can be enough. Works for approachable products that want gentle depth.
+
+**Layered shadows** — Rich, premium, dimensional. Multiple shadow layers create realistic depth. Stripe and Mercury use this approach. Best for cards that need to feel like physical objects.
+
+**Surface color shifts** — Background tints establish hierarchy without any shadows. A card at `#fff` on a `#f8fafc` background already feels elevated.
+
+```css
+/* Borders-only approach */
+--border: rgba(0, 0, 0, 0.08);
+--border-subtle: rgba(0, 0, 0, 0.05);
+border: 0.5px solid var(--border);
+
+/* Single shadow approach */
+--shadow: 0 1px 3px rgba(0, 0, 0, 0.08);
+
+/* Layered shadow approach */
+--shadow-layered:
+  0 0 0 0.5px rgba(0, 0, 0, 0.05), 0 1px 2px rgba(0, 0, 0, 0.04), 0 2px 4px rgba(0, 0, 0, 0.03),
+  0 4px 8px rgba(0, 0, 0, 0.02);
+```
+
+## Card Layouts
+
+Monotonous card layouts are lazy design. A metric card doesn't have to look like a plan card doesn't have to look like a settings card.
+
+Design each card's internal structure for its specific content — but keep the surface treatment consistent: same border weight, shadow depth, corner radius, padding scale, typography.
+
+## Isolated Controls
+
+UI controls deserve container treatment. Date pickers, filters, dropdowns — these should feel like crafted objects.
+
+**Never use native form elements for styled UI.** Native `<select>`, `<input type="date">`, and similar elements render OS-native dropdowns that cannot be styled. Build custom components instead:
+
+- Custom select: trigger button + positioned dropdown menu
+- Custom date picker: input + calendar popover
+- Custom checkbox/radio: styled div with state management
+
+Custom select triggers must use `display: inline-flex` with `white-space: nowrap` to keep text and chevron icons on the same row.
+
+## Typography Hierarchy
+
+Build distinct levels that are visually distinguishable at a glance:
+
+- **Headlines** — heavier weight, tighter letter-spacing for presence
+- **Body** — comfortable weight for readability
+- **Labels/UI** — medium weight, works at smaller sizes
+- **Data** — often monospace, needs `tabular-nums` for alignment
+
+Don't rely on size alone. Combine size, weight, and letter-spacing to create clear hierarchy. If you squint and can't tell headline from body, the hierarchy is too weak.
+
+## Monospace for Data
+
+Numbers, IDs, codes, timestamps belong in monospace. Use `tabular-nums` for columnar alignment. Mono signals "this is data."
+
+## Iconography
+
+Icons clarify, not decorate — if removing an icon loses no meaning, remove it. Choose a consistent icon set and stick with it throughout the product.
+
+Give standalone icons presence with subtle background containers. Icons next to text should align optically, not mathematically.
+
+## Animation
+
+Keep it fast and functional. Micro-interactions (hover, focus) should feel instant — around 150ms. Larger transitions (modals, panels) can be slightly longer — 200-250ms.
+
+Use smooth deceleration easing (ease-out variants). Avoid spring/bounce effects in professional interfaces — they feel playful, not serious.
+
+## Contrast Hierarchy
+
+Build a four-level system: foreground (primary) → secondary → muted → faint. Use all four consistently.
+
+## Color Carries Meaning
+
+Gray builds structure. Color communicates — status, action, emphasis, identity. Unmotivated color is noise. Color that reinforces the product's world is character.
+
+## Navigation Context
+
+Screens need grounding. A data table floating in space feels like a component demo, not a product. Consider including:
+
+- **Navigation** — sidebar or top nav showing where you are in the app
+- **Location indicator** — breadcrumbs, page title, or active nav state
+- **User context** — who's logged in, what workspace/org
+
+When building sidebars, consider using the same background as the main content area. Rely on a subtle border for separation rather than different background colors.
+
+## Dark Mode
+
+Dark interfaces have different needs:
+
+**Borders over shadows** — Shadows are less visible on dark backgrounds. Lean more on borders for definition.
+
+**Adjust semantic colors** — Status colors (success, warning, error) often need to be slightly desaturated for dark backgrounds.
+
+**Same structure, different values** — The hierarchy system still applies, just with inverted values.

package/vendor/skills/skills/interface-design/references/validation.md

@@ -0,0 +1,51 @@
+# Memory Management
+
+When and how to update `.interface-design/system.md`.
+
+## When to Add Patterns
+
+Add to system.md when:
+
+- Component used 2+ times
+- Pattern is reusable across the project
+- Has specific measurements worth remembering
+
+## Pattern Format
+
+```markdown
+### Button Primary
+
+- Height: 36px
+- Padding: 12px 16px
+- Radius: 6px
+- Font: 14px, 500 weight
+```
+
+## Don't Document
+
+- One-off components
+- Temporary experiments
+- Variations better handled with props
+
+## Pattern Reuse
+
+Before creating a component, check system.md:
+
+- Pattern exists? Use it.
+- Need variation? Extend, don't create new.
+
+Memory compounds: each pattern saved makes future work faster and more consistent.
+
+---
+
+# Validation Checks
+
+If system.md defines specific values, check consistency:
+
+**Spacing** — All values multiples of the defined base?
+
+**Depth** — Using the declared strategy throughout? (borders-only means no shadows)
+
+**Colors** — Using defined palette, not random hex codes?
+
+**Patterns** — Reusing documented patterns instead of creating new?

package/vendor/skills/skills/k8s-security-policies/SKILL.md

@@ -0,0 +1,352 @@
+---
+name: k8s-security-policies
+description: Implement Kubernetes security policies including NetworkPolicy, PodSecurityPolicy, and RBAC for production-grade security. Use when securing Kubernetes clusters, implementing network isolation, or enforcing pod security standards.
+---
+
+# Kubernetes Security Policies
+
+Comprehensive guide for implementing NetworkPolicy, PodSecurityPolicy, RBAC, and Pod Security Standards in Kubernetes.
+
+## Purpose
+
+Implement defense-in-depth security for Kubernetes clusters using network policies, pod security standards, and RBAC.
+
+## When to Use This Skill
+
+- Implement network segmentation
+- Configure pod security standards
+- Set up RBAC for least-privilege access
+- Create security policies for compliance
+- Implement admission control
+- Secure multi-tenant clusters
+
+## Pod Security Standards
+
+### 1. Privileged (Unrestricted)
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: privileged-ns
+  labels:
+    pod-security.kubernetes.io/enforce: privileged
+    pod-security.kubernetes.io/audit: privileged
+    pod-security.kubernetes.io/warn: privileged
+```
+
+### 2. Baseline (Minimally restrictive)
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: baseline-ns
+  labels:
+    pod-security.kubernetes.io/enforce: baseline
+    pod-security.kubernetes.io/audit: baseline
+    pod-security.kubernetes.io/warn: baseline
+```
+
+### 3. Restricted (Most restrictive)
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: restricted-ns
+  labels:
+    pod-security.kubernetes.io/enforce: restricted
+    pod-security.kubernetes.io/audit: restricted
+    pod-security.kubernetes.io/warn: restricted
+```
+
+## Network Policies
+
+### Default Deny All
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-all
+  namespace: production
+spec:
+  podSelector: {}
+  policyTypes:
+    - Ingress
+    - Egress
+```
+
+### Allow Frontend to Backend
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-frontend-to-backend
+  namespace: production
+spec:
+  podSelector:
+    matchLabels:
+      app: backend
+  policyTypes:
+    - Ingress
+  ingress:
+    - from:
+        - podSelector:
+            matchLabels:
+              app: frontend
+      ports:
+        - protocol: TCP
+          port: 8080
+```
+
+### Allow DNS
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-dns
+  namespace: production
+spec:
+  podSelector: {}
+  policyTypes:
+    - Egress
+  egress:
+    - to:
+        - namespaceSelector:
+            matchLabels:
+              name: kube-system
+      ports:
+        - protocol: UDP
+          port: 53
+```
+
+**Reference:** See `assets/network-policy-template.yaml`
+
+## RBAC Configuration
+
+### Role (Namespace-scoped)
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: pod-reader
+  namespace: production
+rules:
+  - apiGroups: [""]
+    resources: ["pods"]
+    verbs: ["get", "watch", "list"]
+```
+
+### ClusterRole (Cluster-wide)
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: secret-reader
+rules:
+  - apiGroups: [""]
+    resources: ["secrets"]
+    verbs: ["get", "watch", "list"]
+```
+
+### RoleBinding
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: read-pods
+  namespace: production
+subjects:
+  - kind: User
+    name: jane
+    apiGroup: rbac.authorization.k8s.io
+  - kind: ServiceAccount
+    name: default
+    namespace: production
+roleRef:
+  kind: Role
+  name: pod-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+**Reference:** See `references/rbac-patterns.md`
+
+## Pod Security Context
+
+### Restricted Pod
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: secure-pod
+spec:
+  securityContext:
+    runAsNonRoot: true
+    runAsUser: 1000
+    fsGroup: 1000
+    seccompProfile:
+      type: RuntimeDefault
+  containers:
+    - name: app
+      image: myapp:1.0
+      securityContext:
+        allowPrivilegeEscalation: false
+        readOnlyRootFilesystem: true
+        capabilities:
+          drop:
+            - ALL
+```
+
+## Policy Enforcement with OPA Gatekeeper
+
+### ConstraintTemplate
+
+```yaml
+apiVersion: templates.gatekeeper.sh/v1
+kind: ConstraintTemplate
+metadata:
+  name: k8srequiredlabels
+spec:
+  crd:
+    spec:
+      names:
+        kind: K8sRequiredLabels
+      validation:
+        openAPIV3Schema:
+          type: object
+          properties:
+            labels:
+              type: array
+              items:
+                type: string
+  targets:
+    - target: admission.k8s.gatekeeper.sh
+      rego: |
+        package k8srequiredlabels
+        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
+          provided := {label | input.review.object.metadata.labels[label]}
+          required := {label | label := input.parameters.labels[_]}
+          missing := required - provided
+          count(missing) > 0
+          msg := sprintf("missing required labels: %v", [missing])
+        }
+```
+
+### Constraint
+
+```yaml
+apiVersion: constraints.gatekeeper.sh/v1beta1
+kind: K8sRequiredLabels
+metadata:
+  name: require-app-label
+spec:
+  match:
+    kinds:
+      - apiGroups: ["apps"]
+        kinds: ["Deployment"]
+  parameters:
+    labels: ["app", "environment"]
+```
+
+## Service Mesh Security (Istio)
+
+### PeerAuthentication (mTLS)
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: PeerAuthentication
+metadata:
+  name: default
+  namespace: production
+spec:
+  mtls:
+    mode: STRICT
+```
+
+### AuthorizationPolicy
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+  name: allow-frontend
+  namespace: production
+spec:
+  selector:
+    matchLabels:
+      app: backend
+  action: ALLOW
+  rules:
+    - from:
+        - source:
+            principals: ["cluster.local/ns/production/sa/frontend"]
+```
+
+## Best Practices
+
+1. **Implement Pod Security Standards** at namespace level
+2. **Use Network Policies** for network segmentation
+3. **Apply least-privilege RBAC** for all service accounts
+4. **Enable admission control** (OPA Gatekeeper/Kyverno)
+5. **Run containers as non-root**
+6. **Use read-only root filesystem**
+7. **Drop all capabilities** unless needed
+8. **Implement resource quotas** and limit ranges
+9. **Enable audit logging** for security events
+10. **Regular security scanning** of images
+
+## Compliance Frameworks
+
+### CIS Kubernetes Benchmark
+
+- Use RBAC authorization
+- Enable audit logging
+- Use Pod Security Standards
+- Configure network policies
+- Implement secrets encryption at rest
+- Enable node authentication
+
+### NIST Cybersecurity Framework
+
+- Implement defense in depth
+- Use network segmentation
+- Configure security monitoring
+- Implement access controls
+- Enable logging and monitoring
+
+## Troubleshooting
+
+**NetworkPolicy not working:**
+
+```bash
+# Check if CNI supports NetworkPolicy
+kubectl get nodes -o wide
+kubectl describe networkpolicy <name>
+```
+
+**RBAC permission denied:**
+
+```bash
+# Check effective permissions
+kubectl auth can-i list pods --as system:serviceaccount:default:my-sa
+kubectl auth can-i '*' '*' --as system:serviceaccount:default:my-sa
+```
+
+## Reference Files
+
+- `assets/network-policy-template.yaml` - Network policy examples
+- `assets/pod-security-template.yaml` - Pod security policies
+- `references/rbac-patterns.md` - RBAC configuration patterns
+
+## Related Skills
+
+- `k8s-manifest-generator` - For creating secure manifests
+- `gitops-workflow` - For automated policy deployment