dongarandClaude Opus 5.5
1ad0b2147d
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 1m22s
Development Plan M0.1. Every section reference in code, tests, specs/, the example config, the tuning guide, and the CLAUDE.md and README files now cites docs/Architecture.md (P, L, D, O, X, Q) instead of the old spec's A-H, and docs/Architecture-Build-Spec.md is deleted (git keeps it). The plan's old-to-new table goes with it. Mostly mechanical, with a per-site choice where one old section split: A4 became L2 where it meant stop/abandon/the loop and L3 where it meant approvals; A10 became L6 in the context-budget code and L7 elsewhere; B2 became D4 for outbound Gitea and publishing and D5 for review intake; 'A3 step N' became the matching step of L8's boot sequence. Comments describing behaviour the architecture drops (planning always escalating, thresholds tuned at an old build step) now describe the current code and point at the Development Plan. docs/Architecture.md gains one line the rewrite missed: intake outages delay but never fail work (old B2), now in L5, where the poller and Matrix code cite it. Comments and docs only; no behaviour change. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE
23 lines
1.1 KiB
Markdown
23 lines
1.1 KiB
Markdown
# Nisse
|
|
|
|
Monorepo for two self-hosted AI agents (`nisse-dev`, `nisse-ops`) over a shared
|
|
library (`nisse-core`), one package per directory.
|
|
|
|
**Read the architecture before making design decisions.** The system-level
|
|
specification is `docs/Architecture.md`, and how it gets built is
|
|
`docs/Development-Plan.md`. Requirements that look like
|
|
free choices — gating structure, state durability, LLM access paths, permission
|
|
policy — are usually settled there.
|
|
|
|
## Working conventions
|
|
|
|
- **Ask when anything is unclear.** Do not assume the operator always knows
|
|
exactly what they want; surfacing ambiguity beats guessing.
|
|
- **Plan first.** Before implementing a build-order step or any nontrivial
|
|
change, present a short implementation plan (scope, layout, API sketch,
|
|
deferrals) and get operator sign-off. Code lands as a Gitea PR afterwards.
|
|
- **Script repeated tasks.** If a job takes the same multiple commands more than
|
|
once, save it as a shell script (e.g. in `~/bin`) instead of retyping it.
|
|
- **Strongly prefer automated tests over manual testing.** Every new feature or
|
|
bug fix includes at least one new test verifying its behavior.
|