feat: publish HoloLake model-native living system source

This commit is contained in:
冰朔 2026-08-03 10:04:41 +08:00
commit c395dd3a99
2467 changed files with 615073 additions and 0 deletions

View file

@ -0,0 +1,133 @@
# Create Architecture Decision Record
Use this command when you need to document an architectural decision made during a task.
Inspired by [adr-tools](https://github.com/npryce/adr-tools) (Nygard format), adapted for Laputa's frontmatter-based note format.
## When to use this
Create an ADR when your work involves any of these:
- Choosing a storage strategy (vault vs app settings vs database)
- Adding or removing a major dependency
- Supporting a new platform or target
- Introducing or removing a core abstraction
- Making a cross-cutting decision that affects how future code should be written
Do NOT create ADRs for: bug fixes, UI styling, refactors that preserve behavior, or test additions.
## Creating a new ADR
### 1. Find the next ID
```bash
ls docs/adr/*.md | grep -oP '\d{4}' | sort -n | tail -1 | xargs -I{} printf '%04d\n' $(({} + 1))
```
If no files exist yet, start at `0001`.
### 2. Create the file
Filename: `docs/adr/NNNN-short-kebab-title.md`
Template:
```markdown
---
type: ADR
id: "NNNN"
title: "Short decision title"
status: active
date: YYYY-MM-DD
---
## Context
The issue motivating this decision, and any context that influences or constrains it.
## Decision
**The change we're proposing or have agreed to implement.** State it clearly in one or two sentences — bold so it stands out.
## Options considered
- **Option A** (chosen): brief description — pros / cons
- **Option B**: brief description — pros / cons
- **Option C**: brief description — pros / cons
## Consequences
What becomes easier or harder as a result?
What risks does this introduce that will need to be mitigated?
What would trigger re-evaluation of this decision?
## Advice
*(optional)* Input received before making this decision — who was consulted, what they said.
Omit this section if the decision was made without external input.
```
### 3. Update the index
Add a row to `docs/adr/README.md`:
```markdown
| [NNNN](NNNN-short-kebab-title.md) | Title | active |
```
### 4. Include in the same commit as the feature
```bash
git add docs/adr/NNNN-*.md docs/adr/README.md
# fold into the feature commit — do not create a separate commit just for the ADR
```
---
## Superseding an existing ADR
Equivalent of `adr new -s <N>` from adr-tools — do this in two steps:
### Step 1: Mark the old ADR as superseded
Edit the existing file — add `superseded_by` and update `status`:
```yaml
---
type: ADR
id: "000N"
title: "Old decision title"
status: superseded # ← change from active
superseded_by: "NNNN" # ← add this
date: YYYY-MM-DD
---
```
**Never edit the content sections** of an active ADR — only the status metadata.
### Step 2: Create the new ADR
Follow the steps above. In the **Context** section, reference the superseded ADR:
```markdown
## Context
Supersedes [ADR-000N](000N-old-title.md).
[explain why the old decision no longer holds]
```
### Step 3: Update the README index
Change the old row's status to `superseded`, add the new row.
---
## Best practices (from adr-tools / Nygard)
- **One decision per ADR** — if you find yourself writing "and also", split it
- **Write Decision first** — if you can't state it in 1-2 sentences, the decision is too vague
- **Context is the "why now"** — what forced this decision to be made today?
- **Consequences should include negatives** — a one-sided ADR is a red flag
- **Committed = immutable** — once pushed, the content doesn't change; only status metadata does
- **If in doubt, create one** — cheaper to have an unnecessary ADR than to lose context
- Date = today's date, `YYYY-MM-DD`

View file

@ -0,0 +1,42 @@
# /laputa-done <task_id>
Mark a Laputa task as done: add completion comment, move to In Review, then self-dispatch the next task.
Run this after Phase 1 (Playwright) and Phase 2 (native app QA) both pass **and `git push origin main` has succeeded**.
⚠️ A task is NOT done until the push succeeds. If the push is blocked by the pre-push hook (clippy, tests, CodeScene, build):
- Read the error
- Fix it (never use `--no-verify`)
- Commit the fix and push again
- Repeat until push exits with code 0
## Steps
**1. Add completion comment to the task**
Summarize what was done — this is the context Luca and Brian will read in Todoist:
```bash
curl -s -X POST "https://api.todoist.com/api/v1/comments" \
-H "Authorization: Bearer $TODOIST_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"task_id": "$ARGUMENTS",
"content": "✅ Implementation complete.\n\n**What changed:** [brief summary of the implementation]\n**ADR:** [if an ADR was created, reference it here; otherwise omit]\n**Playwright:** all tests pass\n**Native QA:** tested with pnpm tauri dev — [describe what was tested and what was observed]"
}'
```
**2. Move task to In Review**
```bash
curl -s -X POST "https://api.todoist.com/api/v1/tasks/$ARGUMENTS/move" \
-H "Authorization: Bearer $TODOIST_API_KEY" \
-H "Content-Type: application/json" \
-d '{"section_id": "6g3XjX33FF4Vj86M"}'
```
**3. Pick the next task**
Run `/laputa-next-task` to get the next task and start working on it immediately.
If there are no tasks, `/laputa-next-task` will wait 10 minutes and retry automatically. Do NOT exit — stay alive and let it loop.

View file

@ -0,0 +1,60 @@
# /laputa-next-task
Pick the next Laputa task from Todoist and move it to In Progress.
Priority order: **To Rework** first, then **Open** (sorted by Todoist priority p1→p4).
## Steps
1. Fetch tasks from To Rework (`6g6QqvR9rRpvJWvv`), then Open (`6g3XjWR832hVHhCM`)
2. **Sort by priority — this is mandatory.** Todoist returns tasks in arbitrary order. You must sort them yourself:
- Todoist priority field: `4` = p1 (urgent), `3` = p2, `2` = p3, `1` = p4
- Sort descending by `priority` field (4 first, 1 last)
- To Rework tasks always come before Open tasks regardless of priority
- **Never pick a p3/p4 task if a p1/p2 task exists in the same section**
3. Take the first task from the sorted list
4. Move it to In Progress (`6g3XjWjfmJFcGgHM`) via Todoist API:
```bash
curl -s -X POST "https://api.todoist.com/api/v1/tasks/<task_id>/move" \
-H "Authorization: Bearer $TODOIST_API_KEY" \
-H "Content-Type: application/json" \
-d '{"section_id": "6g3XjWjfmJFcGgHM"}'
```
5. Add a "started" comment to the task:
```bash
curl -s -X POST "https://api.todoist.com/api/v1/comments" \
-H "Authorization: Bearer $TODOIST_API_KEY" \
-H "Content-Type: application/json" \
-d '{"task_id": "<task_id>", "content": "🚀 Starting work. [Brief description of approach or what needs to be fixed]"}'
```
6. Fetch the full task details (description, comments) from Todoist:
```bash
curl -s "https://api.todoist.com/api/v1/tasks/<task_id>" \
-H "Authorization: Bearer $TODOIST_API_KEY"
curl -s "https://api.todoist.com/api/v1/comments?task_id=<task_id>" \
-H "Authorization: Bearer $TODOIST_API_KEY"
```
6. For To Rework tasks: read the ❌ QA failed comment — it tells you exactly what to fix
7. Output: task ID, title, and full description so you can start working immediately
If no tasks are available in either section → wait 10 minutes and try again (loop forever):
```bash
while true; do
# ... check tasks ...
if no_tasks; then
sleep 600 # 10 minutes
else
break # got a task, proceed
fi
done
```
Do NOT exit when there are no tasks. Keep looping until a task appears. This keeps Claude Code alive permanently — the watchdog is a safety net only, not the primary dispatcher.

View file

@ -0,0 +1,11 @@
{
"permissions": {
"allow": [
"mcp__codescene__*",
"Read(*)",
"Bash(cat*)",
"Bash(ls*)",
"Write(*)"
]
}
}