Feat/k8s agent sandbox integration

.agents/skills/backend-services/REFERENCE.md

@@ -129,6 +129,7 @@ Rules:
 
 - Use `saveFormAction` for validated form submissions.
 - Use `simpleAction` for non-form actions.
+- Older server actions used `return new SuccessActionResult(returnData, "App created successfully.");` but this is no longer needed; if theres a return value, just return the variable directly and success messages should be handled in component not server action.
 - Put authorization checks inside the callback before service calls.
 - Let the wrappers produce success payloads; do not manually construct them unless returning data.
 

.agents/skills/grill-with-docs/CONTEXT-FORMAT.md → .agents/skills/domain-modeling/CONTEXT-FORMAT.md

@@ -10,7 +10,7 @@
 ## Language
 
 **Order**:
-{A concise description of the term}
+{A one or two sentence description of the term}
 _Avoid_: Purchase, transaction
 
 **Invoice**:
@@ -20,31 +20,14 @@ _Avoid_: Bill, payment request
 **Customer**:
 A person or organization that places orders.
 _Avoid_: Client, buyer, account
-
-## Relationships
-
-- An **Order** produces one or more **Invoices**
-- An **Invoice** belongs to exactly one **Customer**
-
-## Example dialogue
-
-> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
-> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed."
-
-## Flagged ambiguities
-
-- "account" was used to mean both **Customer** and **User** — resolved: these are distinct concepts.
 ```
 
 ## Rules
 
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
-- **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution.
-- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.
-- **Show relationships.** Use bold term names and express cardinality where obvious.
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
 - **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
 - **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
-- **Write an example dialogue.** A conversation between a dev and a domain expert that demonstrates how the terms interact naturally and clarifies boundaries between related concepts.
 
 ## Single vs multi-context repos
 

.agents/skills/domain-modeling/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: domain-modeling
+description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
+---
+
+# Domain Modeling
+
+Actively build and sharpen the project's domain model as you design. This is the *active* discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `CONTEXT.md` for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
+
+## File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).

.agents/skills/frontend-ui-patterns/REFERENCE.md

@@ -50,15 +50,15 @@ Use helpers from `action-wrapper.utils.ts`:
 Every form follows this pattern:
 
 1. Define or import a Zod schema.
-2. `useForm<T>({ resolver: zodResolver(schema) })`
+2. Import `z` from `"zod"` and use the schema input/output types: `useForm<z.input<typeof schema>, unknown, z.output<typeof schema>>({ resolver: zodResolver(schema) })`.
 3. Wrap in shadcn `<Form>` provider.
 4. Use `<FormField>` with `control`, `name`, and `render`.
 5. Submit through `Toast.fromAction()` or `Actions.run()`.
 
 ```tsx
 'use client'
 
-const form = useForm<CreateAppSchema>({
+const form = useForm<z.input<typeof createAppSchema>, unknown, z.output<typeof createAppSchema>>({
     resolver: zodResolver(createAppSchema),
 });
 
@@ -121,7 +121,7 @@ const result = await Actions.run(() => getProjectDetails(projectId));
 Map validation errors back to the form with:
 
 ```tsx
-FormUtils.mapValidationErrorsToForm(serverActionResult, form);
+FormUtils.mapValidationErrorsToForm<typeof zodModel>(serverActionResult, form);
 ```
 
 ## Zustand State Stores
@@ -176,58 +176,154 @@ Columns are tuples: `[accessorKey, headerLabel, isVisible, renderFn?]`
 
 ## Dialogs
 
-Use Zustand-backed global dialogs instead of one-off dialog state.
+Use Zustand-backed global dialogs instead of one-off dialog state. Keep trigger and dialog content in separate components (often separate files for reuse).
 
-### `useDialog`
+### Pattern: Trigger + Dialog Content
 
-Prefer responsive sizing options:
+**Trigger component** — opens dialog via `useDialog().openDialog()`:
 
 ```tsx
-const { openDialog } = useDialog();
-
-<Button
-    type="button"
-    onClick={() => openDialog(<ImportDialog />, {
-        width: 'calc(100vw - 2rem)',
-        maxWidth: '760px',
-        maxHeight: '90vh',
-    })}
->
-    Import
-</Button>
+'use client'
+
+import { useDialog } from "@/frontend/states/zustand.states";
+
+export default function MyTrigger({ children, someProp }: { children: React.ReactNode; someProp: string }) {
+    const { openDialog } = useDialog();
+
+    const handleOpen = () => {
+        openDialog(<MyDialogContent someProp={someProp} />, { maxWidth: '520px' });
+    };
+
+    return (
+        <div onClick={handleOpen}>
+            {children}
+        </div>
+    );
+}
 ```
 
-Inside dialog content, use `useDialogContext()` to close or resolve:
+**Dialog content — variant A: with form** (react-hook-form + Server Action):
 
 ```tsx
-function ImportDialog() {
+'use client'
+
+import { useDialogContext } from "@/frontend/states/dialog-context";
+import { DialogHeader, DialogTitle, DialogFooter } from "@/components/ui/dialog";
+import { ScrollArea } from "@/components/ui/scroll-area";
+
+function MyFormDialog({ someProp }: { someProp: string }) {
+    const { closeDialog } = useDialogContext();
+
+    const form = useForm<z.input<typeof mySchema>, unknown, z.output<typeof mySchema>>({
+        resolver: zodResolver(mySchema),
+        defaultValues: { name: someProp ?? '' },
+    });
+
+    const [state, formAction] = useActionState(
+        (prev, payload) => myServerAction(prev, payload),
+        FormUtils.getInitialFormState<typeof mySchema>()
+    );
+
+    useEffect(() => {
+        if (state.status === 'success') {
+            toast.success(state.message ?? 'Saved.');
+            closeDialog();
+        }
+        FormUtils.mapValidationErrorsToForm<typeof mySchema>(state, form);
+    }, [state]);
+
+    return (
+        <Form {...form}>
+            <form
+                className="flex max-h-[80vh] flex-col overflow-hidden"
+                action={() => form.handleSubmit((data) => formAction(data))()}
+            >
+                <DialogHeader>
+                    <DialogTitle>My Dialog</DialogTitle>
+                </DialogHeader>
+                <ScrollArea className="mt-4 flex-1 min-h-0">
+                    <div className="space-y-4 px-2">
+                        {/* form fields */}
+                    </div>
+                </ScrollArea>
+                <DialogFooter className="mt-4">
+                    <SubmitButton>Save</SubmitButton>
+                    <Button type="button" variant="outline" onClick={() => closeDialog()}>
+                        Cancel
+                    </Button>
+                </DialogFooter>
+            </form>
+        </Form>
+    );
+}
+```
+
+The success (primary) button is always the first button in the footer, cancel is always the last.
+
+**Dialog content — variant B: without form** (simple confirm/info dialog):
+
+```tsx
+'use client'
+
+import { useDialogContext } from "@/frontend/states/dialog-context";
+import { DialogHeader, DialogTitle, DialogDescription, DialogFooter } from "@/components/ui/dialog";
+
+function MyConfirmDialog({ itemName }: { itemName: string }) {
     const { closeDialog } = useDialogContext();
 
     return (
         <>
             <DialogHeader>
-                <DialogTitle>Import</DialogTitle>
-                <DialogDescription>Optional description</DialogDescription>
+                <DialogTitle>Delete {itemName}?</DialogTitle>
+                <DialogDescription>This action cannot be undone.</DialogDescription>
             </DialogHeader>
-            <div className="space-y-4">
-                <div className="flex justify-end gap-2">
-                    <Button type="button" variant="outline" onClick={() => closeDialog(false)}>
-                        Cancel
-                    </Button>
-                    <Button type="button" onClick={() => closeDialog(true)}>
-                        Import
-                    </Button>
-                </div>
-            </div>
+           {/* Here additional content of the dialog can be added. If allot of content -> use ScrollArea */}
+            <DialogFooter className="mt-4">
+                <Button type="button" variant="outline" onClick={() => closeDialog(false)}>
+                    Cancel
+                </Button>
+                <Button type="button" variant="destructive" onClick={() => closeDialog(true)}>
+                    Delete
+                </Button>
+            </DialogFooter>
         </>
     );
 }
 ```
 
-Simple fixed-width dialogs can still use:
+Await result from trigger:
 
 ```tsx
-openDialog(<PublicDeployKeyDialog publicKey={publicKey} />, '680px');
+const confirmed = await openDialog(<MyConfirmDialog itemName="foo" />);
+if (confirmed) { /* delete */ }
+```
+
+### `useDialog` Sizing
+
+Second arg: `DialogSizeProps` object or shorthand string (= `maxWidth`):
+
+```tsx
+// Full size control
+openDialog(<Content />, {
+    width: 'calc(100vw - 2rem)',
+    maxWidth: '760px',
+    maxHeight: '90vh',
+});
+
+// Shorthand: string = maxWidth
+openDialog(<Content />, '680px');
+```
+
+### `useDialogContext`
+
+Inside dialog content, close with optional result:
+
+```tsx
+const { closeDialog } = useDialogContext();
+
+closeDialog();        // close, no result
+closeDialog(someData); // close, pass result to openDialog() awaiter
+```
 ```
 
 ### Confirm/Input Dialogs

.agents/skills/frontend-ui-patterns/SKILL.md

@@ -35,6 +35,7 @@ When creating or updating frontend UI:
 ## Forms And Actions
 
 - Add route-safe validation with shared or local Zod schemas.
+- With Zod 4 and `zodResolver`, type every form with the schema's input and output types. Import `z` from `"zod"` and use `useForm<z.input<typeof schema>, unknown, z.output<typeof schema>>({ resolver: zodResolver(schema), ... })`. Do not use `z.infer` as the `useForm` field-values type when the schema has coercion, transforms, preprocessors, or defaults.
 - Map server validation errors back with `FormUtils.mapValidationErrorsToForm(...)`.
 - Use `SubmitButton` for form submits when possible.
 

.agents/skills/grill-me/SKILL.md

@@ -1,10 +1,7 @@
 ---
 name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
 ---
 
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.
+Run a `/grilling` session.