| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 5 | 6 | 0% |
| Commands | 0 | 1 | 0 | 0% |
| Section tags | 0 | 1 | 2 | 0% |
What each file covers
Sections
0 shared · 5 only in A · 6 only in B- − Your role: on-prem student to a Teacher LLM
- − The standard loop
- − What you do
- − What you do NOT do
- − Per-session
- + Output discipline: compact, hand-typeable reports
- + Constraints
- + Standard report types
- + Conventions
- + What NOT to include
- + Example layouts
Commands
0 shared · 1 only in A · 0 only in B- − git pull
Section tags
0 shared · 1 only in A · 2 only in B- − do-not
- + code-style
- + types
Line diff
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
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
@@ −1 +1 @@
1−# Your role: on-prem student to a Teacher LLM
1+# Output discipline: compact, hand-typeable reports
22
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/`.
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.
75
8−## The standard loop
6+## Constraints
97
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−```
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`
2113
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.
14+## Standard report types
2415
25−## What you do
16+Each playbook produces one of these:
2617
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`.
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 |
3726
38−## What you do NOT do
27+The exact field set per type is defined in the corresponding playbook.
3928
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).
29+## Conventions
4730
48−## Per-session
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).
4939
50−On first conversation each session, run `cline-playbooks/orient.md` to load project context.
51−Then proceed to the task at hand.
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+```
5271
