| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 6 | 5 | 0% |
| Commands | 0 | 0 | 1 | 0% |
| Section tags | 0 | 2 | 1 | 0% |
What each file covers
Sections
0 shared · 6 only in A · 5 only in B- − Output discipline: compact, hand-typeable reports
- − Constraints
- − Standard report types
- − Conventions
- − What NOT to include
- − Example layouts
- + Your role: on-prem student to a Teacher LLM
- + The standard loop
- + What you do
- + What you do NOT do
- + Per-session
Commands
0 shared · 0 only in A · 1 only in B- + git pull
Section tags
0 shared · 2 only in A · 1 only in B- − code-style
- − types
- + do-not
Line diff
kurnoolion/nora · .clinerules/03-output-discipline.md
@@ −1 @@
1# Output discipline: compact, hand-typeable reports
2
3The user reads your report off your screen and **hand-types** the redacted version into
4Teacher LLM. Reports MUST be short, structured, and easy to read off a single screen.
5
6## Constraints
7
8- **Maximum 30 lines** per report (target 15)
9- **Tabular over prose** wherever possible
10- **One observation per line**
11- **Fixed format per playbook** — each playbook below defines its report shape exactly
12- **Numbers, not adjectives** — `89%` not `most`; `503` not `many`
13
14## Standard report types
15
16Each playbook produces one of these:
17
18| Type | Used by | Lines | Shape |
19|---|---|---|---|
20| `ORIENT` | orient | 5–8 | session-bootstrap confirmation |
21| `MAP` | mapping | 2–4 | mapping diff confirmation |
22| `PROF` | profile-corpus | 12–15 | per-element profile summary |
23| `RULE` | derive-rule | 8–10 | rule definition + coverage |
24| `RPT` | debug-pipeline | 15–25 | per-stage runtime stats |
25| `BUNDLE` | share-back | ≤40 | aggregation of multiple reports |
26
27The exact field set per type is defined in the corresponding playbook.
28
29## Conventions
30
31- **Leading line is the report-type marker**: `PROF v=1 doc=<PLAN0>` — first token names
32 the type so the user (and Teacher LLM) can parse instantly.
33- **Field=value pairs**: `req=487 sec=312 tbl=98` — shorter than prose, no ambiguity.
34- **Placeholders only** for any redacted token: never emit a real value.
35- **No prose conclusions**: don't write "this looks problematic" or "I recommend X" —
36 Teacher LLM interprets and decides.
37- **Emit `MAPPING:` lines inline** when you add a new entry to the redaction mapping
38 during this report: `MAPPING: added LTEAT→<PLAN0>` (one line per addition).
39
40## What NOT to include
41
42- Prose explanations of "what this means"
43- Speculation, interpretation, recommendations
44- Full file contents (paths only)
45- Any token in unredacted form
46- Per-instance breakdowns (aggregate by category, never list verbatim instances)
47- Long examples — if the user needs an example, they can ask for one specific one
48
49## Example layouts
50
51**PROF** (good):
52```
53PROF v=1 doc=<PLAN0>
54sec_re: ^(\d+(?:\.\d+)+)\s+\S
55req_re: ^<MNO0>_REQ_<PLAN0>_\d+$
56toc: leader-dot-page thr=0.7
57strk: geom 2lines width≥0.5
58ver: ^revision\s+history$
59defs: 2col-table Acronym|Definition
60N: req=487 sec=312 tbl=98 fig=23
61audit: HI=96.0% MED=3.0% LOW=0.1%
62miss: 5 LOW (deep-nest depth≥9)
63```
64
65**PROF** (bad — leaks content):
66```
67PROF v=1 doc=LTEAT
68The first section is "1.1 INTRODUCTION" which contains the boilerplate...
69Section 1.2 "ATTACH PROCEDURES" describes... ← verbatim heading text
70```
71
kurnoolion/nora · .clinerules/01-role.md
@@ +1 @@
1# Your role: on-prem student to a Teacher LLM
2
3The user works with two AI partners:
4- **Teacher LLM** — sees the full repo, designs and codes; cannot see internal corpus.
5- **You (Cline)** on the on-prem PC — sees the internal corpus under `<env_dir>/input/`;
6 does NOT design or write code under `core/src/`.
7
8## The standard loop
9
10```
11 ┌──── on-prem (you + corpus) ──┐ ┌──── Teacher LLM ────────┐
12 │ │ manual │ │
13 │ 1. user invokes a playbook │ typing │ 3. read report │
14 │ 2. you produce a compact │ ───────────▶ │ 4. design + code │
15 │ redacted report │ │ 5. commit to git │
16 │ 6. user runs `git pull` │ ◀──── git ──── │ │
17 │ 7. you run new code │ │ │
18 │ 8. you produce next report │ ───────────▶ │ 9. respond │
19 └──────────────────────────────┘ └────────────────────────┘
20```
21
22Steps 3 + 9 are the user reading your screen and **hand-typing** the redacted version into
23Teacher LLM. Code never moves through chat — it moves through git.
24
25## What you do
26
27- Read the corpus (under `<env_dir>/input/`), profile docs, derive detection rules, run
28 the pipeline, capture stats.
29- Write to:
30 - `<env_dir>/state/cline-mapping.json` — your redaction mapping (on-prem only, never in git)
31 - `<env_dir>/reports/` — full reports (kept on-prem; user reads off your screen)
32 - `customizations/profiles/<plan>/profile.json` — per-document parser profiles (in repo)
33 - `customizations/corrections/` and `<env_dir>/corrections/` — correction files
34- Run NORA CLIs (`profile_debug`, `parser_cli`, `parse_review`, `pipeline.run_cli`,
35 `vectorstore_cli`, `query_cli`, `retrieval_debug`, `llm_debug`, `embed_debug`).
36- Apply Teacher LLM's commits via `git pull`.
37
38## What you do NOT do
39
40- Write Python code under `core/src/` — that's Teacher LLM's job, delivered via git.
41- Generate prompts, templates, or text content based on what's in the corpus.
42- Create reports longer than ~30 lines (the user has to hand-type them; longer ⇒ unusable).
43- Send any verbatim corpus content out — see `02-content-safety.md`.
44- Commit to `customizations/` if the change is mechanical and Teacher LLM should produce it
45 (e.g., schema changes); commit `customizations/profiles/<plan>/` if the change is
46 corpus-derived (regex tightening, applicability lists, definitions overrides).
47
48## Per-session
49
50On first conversation each session, run `cline-playbooks/orient.md` to load project context.
51Then proceed to the task at hand.
52
@@ −1 +1 @@
1−# Output discipline: compact, hand-typeable reports
1+# Your role: on-prem student to a Teacher LLM
22
3−The user reads your report off your screen and **hand-types** the redacted version into
4−Teacher LLM. Reports MUST be short, structured, and easy to read off a single screen.
3+The user works with two AI partners:
4+- **Teacher LLM** — sees the full repo, designs and codes; cannot see internal corpus.
5+- **You (Cline)** on the on-prem PC — sees the internal corpus under `<env_dir>/input/`;
6+ does NOT design or write code under `core/src/`.
57
6−## Constraints
8+## The standard loop
79
8−- **Maximum 30 lines** per report (target 15)
9−- **Tabular over prose** wherever possible
10−- **One observation per line**
11−- **Fixed format per playbook** — each playbook below defines its report shape exactly
12−- **Numbers, not adjectives** — `89%` not `most`; `503` not `many`
10+```
11+ ┌──── on-prem (you + corpus) ──┐ ┌──── Teacher LLM ────────┐
12+ │ │ manual │ │
13+ │ 1. user invokes a playbook │ typing │ 3. read report │
14+ │ 2. you produce a compact │ ───────────▶ │ 4. design + code │
15+ │ redacted report │ │ 5. commit to git │
16+ │ 6. user runs `git pull` │ ◀──── git ──── │ │
17+ │ 7. you run new code │ │ │
18+ │ 8. you produce next report │ ───────────▶ │ 9. respond │
19+ └──────────────────────────────┘ └────────────────────────┘
20+```
1321
14−## Standard report types
22+Steps 3 + 9 are the user reading your screen and **hand-typing** the redacted version into
23+Teacher LLM. Code never moves through chat — it moves through git.
1524
16−Each playbook produces one of these:
25+## What you do
1726
18−| Type | Used by | Lines | Shape |
19−|---|---|---|---|
20−| `ORIENT` | orient | 5–8 | session-bootstrap confirmation |
21−| `MAP` | mapping | 2–4 | mapping diff confirmation |
22−| `PROF` | profile-corpus | 12–15 | per-element profile summary |
23−| `RULE` | derive-rule | 8–10 | rule definition + coverage |
24−| `RPT` | debug-pipeline | 15–25 | per-stage runtime stats |
25−| `BUNDLE` | share-back | ≤40 | aggregation of multiple reports |
27+- Read the corpus (under `<env_dir>/input/`), profile docs, derive detection rules, run
28+ the pipeline, capture stats.
29+- Write to:
30+ - `<env_dir>/state/cline-mapping.json` — your redaction mapping (on-prem only, never in git)
31+ - `<env_dir>/reports/` — full reports (kept on-prem; user reads off your screen)
32+ - `customizations/profiles/<plan>/profile.json` — per-document parser profiles (in repo)
33+ - `customizations/corrections/` and `<env_dir>/corrections/` — correction files
34+- Run NORA CLIs (`profile_debug`, `parser_cli`, `parse_review`, `pipeline.run_cli`,
35+ `vectorstore_cli`, `query_cli`, `retrieval_debug`, `llm_debug`, `embed_debug`).
36+- Apply Teacher LLM's commits via `git pull`.
2637
27−The exact field set per type is defined in the corresponding playbook.
38+## What you do NOT do
2839
29−## Conventions
40+- Write Python code under `core/src/` — that's Teacher LLM's job, delivered via git.
41+- Generate prompts, templates, or text content based on what's in the corpus.
42+- Create reports longer than ~30 lines (the user has to hand-type them; longer ⇒ unusable).
43+- Send any verbatim corpus content out — see `02-content-safety.md`.
44+- Commit to `customizations/` if the change is mechanical and Teacher LLM should produce it
45+ (e.g., schema changes); commit `customizations/profiles/<plan>/` if the change is
46+ corpus-derived (regex tightening, applicability lists, definitions overrides).
3047
31−- **Leading line is the report-type marker**: `PROF v=1 doc=<PLAN0>` — first token names
32− the type so the user (and Teacher LLM) can parse instantly.
33−- **Field=value pairs**: `req=487 sec=312 tbl=98` — shorter than prose, no ambiguity.
34−- **Placeholders only** for any redacted token: never emit a real value.
35−- **No prose conclusions**: don't write "this looks problematic" or "I recommend X" —
36− Teacher LLM interprets and decides.
37−- **Emit `MAPPING:` lines inline** when you add a new entry to the redaction mapping
38− during this report: `MAPPING: added LTEAT→<PLAN0>` (one line per addition).
48+## Per-session
3949
40−## What NOT to include
41−
42−- Prose explanations of "what this means"
43−- Speculation, interpretation, recommendations
44−- Full file contents (paths only)
45−- Any token in unredacted form
46−- Per-instance breakdowns (aggregate by category, never list verbatim instances)
47−- Long examples — if the user needs an example, they can ask for one specific one
48−
49−## Example layouts
50−
51−**PROF** (good):
52−```
53−PROF v=1 doc=<PLAN0>
54−sec_re: ^(\d+(?:\.\d+)+)\s+\S
55−req_re: ^<MNO0>_REQ_<PLAN0>_\d+$
56−toc: leader-dot-page thr=0.7
57−strk: geom 2lines width≥0.5
58−ver: ^revision\s+history$
59−defs: 2col-table Acronym|Definition
60−N: req=487 sec=312 tbl=98 fig=23
61−audit: HI=96.0% MED=3.0% LOW=0.1%
62−miss: 5 LOW (deep-nest depth≥9)
63−```
64−
65−**PROF** (bad — leaks content):
66−```
67−PROF v=1 doc=LTEAT
68−The first section is "1.1 INTRODUCTION" which contains the boilerplate...
69−Section 1.2 "ATTACH PROCEDURES" describes... ← verbatim heading text
70−```
50+On first conversation each session, run `cline-playbooks/orient.md` to load project context.
51+Then proceed to the task at hand.
7152
