toolctrl-labs/HiveGrid-Wireframes
9
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reorganize repo structure and standards references

Browse Source
This commit is contained in:
david committed 2026-06-29 05:03:42 +02:00
1 parent 3cb93a81be
commit be2054274d
5885 files changed
+2588 -195
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

01 Regeln/Screen Agent Workflow.md
+5 -3
View File
@@ -22,6 +22,7 @@ This file is the operative checklist. `Screen Agent Workflow - Brainstorming.md`
- MUST check for similar existing flows, screens, reusable patterns and naming conflicts before creating a new flow or screen.
- MUST use internal Planning as the default source of truth.
- MUST use external research only as decision support, and validate relevant research-derived ideas with David before they enter planning.
- MUST use `04 Standards/Subframe UI Standards/` as reference for already validated Subframe, component and layout standards when relevant.
- MUST give an assumption and recommendation before asking David a decision question.
- MUST have David validate every product, UX, screen, state, backlog, scope and research-derived decision.
- MUST keep one small flow or screen package in focus at a time.
@@ -40,6 +41,7 @@ This file is the operative checklist. `Screen Agent Workflow - Brainstorming.md`
- NEVER finalize unvalidated decisions.
- NEVER silently create, delete, rename or split screens.
- NEVER build or edit Subframe without explicit OK for the concrete screen or flow.
- NEVER edit `04 Standards/Subframe UI Standards/` during normal screen work unless David explicitly asks for standards work or validates a systemwide rule that belongs there.
- NEVER overwrite or revert David's manual changes in Obsidian or Subframe.
- NEVER let external examples override internal Planning without making the conflict visible and asking David.
- NEVER create Canvas nodes for normal Toasts, Banners, Inline States, field validation or pure documentation states.
@@ -155,9 +157,9 @@ Then check:
When a ticket is finished, ready for external ticket-system handoff, or David asks for a ticket summary:
- Create or update one Markdown file in `Tickets/`.
- Use the same structure as `Tickets/D-P2 Auth Wireframes.md`.
- Name it clearly after the ticket and area, for example `Tickets/D-P2 Auth Wireframes.md`.
- Create or update one Markdown file in `Tickets/Fertige Tickets/`.
- Use the same structure as `Tickets/Fertige Tickets/D-P2 Auth Wireframes.md`.
- Name it clearly after the ticket and area, for example `Tickets/Fertige Tickets/D-P2 Auth Wireframes.md`.
- Include ticket id, area, status, repo link, central tracker link and working area.
- Summarize what was done, what David validated and what remains Backlog/Open.
- Link every relevant flow package MD, Canvas and Subframe flow.