| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 5 | 7 | 0% |
| Commands | 0 | 1 | 1 | 0% |
| Section tags | 1 | 0 | 0 | 100% |
What each file covers
Sections
0 shared · 5 only in A · 7 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
- + Content safety: nothing proprietary leaves the on-prem machine
- + Redaction protocol
- + Hard rules — never include in your report
- + OK to include (after redaction)
- + Borderline cases
- + What this protects against
- + Mapping snapshot location [D-062]
Commands
0 shared · 1 only in A · 1 only in B- − git pull
- + git push
Section tags
1 shared · 0 only in A · 0 only in B- do-not
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/02-content-safety.md
@@ +1 @@
1# Content safety: nothing proprietary leaves the on-prem machine
2
3The user reads your reports off your screen and hand-types into Teacher LLM. Teacher LLM must NEVER
4see verbatim corpus content, MNO names, plan IDs, requirement IDs, release codes, or any
5file path under `<env_dir>/input/`.
6
7## Redaction protocol
8
9You maintain a literal-string mapping at `<env_dir>/state/cline-mapping.json`. Apply it
10forward (real → placeholder) before emitting any report, and reverse (placeholder → real)
11when acting on Teacher LLM's response.
12
13**Mapping schema**:
14
15```json
16{
17 "version": 1,
18 "mappings": {
19 "<real-string>": "<placeholder>"
20 }
21}
22```
23
24**Placeholder format** — angle-bracketed, category-prefixed, stable index:
25
26| Category | Pattern | Example |
27|---|---|---|
28| MNO short prefix | `<MNO{N}>` | `VZ` → `<MNO0>` |
29| MNO alias | `<MNO{N}_ALIAS>` | `VZW` → `<MNO0_ALIAS>` |
30| MNO full name | `<MNO{N}_NAME>` | `Verizon` → `<MNO0_NAME>` |
31| Plan ID | `<PLAN{N}>` | `LTEAT` → `<PLAN0>` |
32| Plan name | `<PLAN{N}_NAME>` | (use when plan_name differs from plan_id) |
33| Release | `<REL{N}>` | `OA-baseline` → `<REL0>` |
34| Requirement ID | `<REQID-{N}>` | `VZ_REQ_LTEAT_45` → `<REQID-0>` |
35| Standards spec | `<SPEC{N}>` | `3GPP TS 24.301` → keep as-is (public standard, not proprietary) |
36
37`{N}` is a stable index — once allocated, never changes. New entries get the next free index.
38
39Apply substitution **longest-match-first** so `VZ_REQ_LTEAT_45` matches before `VZ`.
40
41The mapping playbook (`cline-playbooks/mapping.md`) describes how to seed and grow this
42file.
43
44## Hard rules — never include in your report
45
46- Verbatim quotes from any document under `<env_dir>/input/`
47- Section heading text > 5 words (treat as title-class quoted prose)
48- Requirement body text (any length)
49- Acronym definitions in full (the expansion phrase IS corpus content)
50- Tabular requirement data
51- Real values for any token in the mapping (always emit the placeholder)
52- Un-redacted file paths under `<env_dir>/input/<...>` (the path components are MNO/RELEASE/PLAN)
53
54## OK to include (after redaction)
55
56- Counts, percentages, ratios
57- Generic regex patterns — `^\d+(?:\.\d+)+\s+\S` is fine
58- Format-class observations — `89% of headings are numbered N.N.N`
59- Coverage stats — `rule catches 487/503`
60- Counts of misses by severity — `HIGH=96%, MED=3%, LOW=0.1%`
61- Source code paths inside the repo — `core/src/parser/structural_parser.py:1243`
62 (those are repo paths, not corpus)
63- Public standards references — `3GPP TS 24.301, Section 5.5.1.2.6` (public knowledge)
64- Domain terminology — `ATTACH`, `EMM`, `NAS` (3GPP standard terms)
65
66## Borderline cases
67
68A regex that ORs corpus-specific values is suspect: `(ATTACH|DETACH|FOO)` is fine if all
69three are public 3GPP terms; not fine if `FOO` is a customer-specific keyword. When unsure,
70add `FOO` to the mapping and emit the redacted form.
71
72When unsure in general: ask the user. Default to redaction.
73
74## What this protects against
75
76A passing observer of the user's hand-typed reports — and Teacher LLM itself, which logs
77conversations — never sees any string that uniquely identifies a customer, document,
78release, or specific requirement. Patterns and counts are sufficient for Teacher LLM to
79update code; concrete values stay on-prem.
80
81## Mapping snapshot location [D-062]
82
83Beyond the live `<env_dir>/state/cline-mapping.json` (forward redaction for outgoing
84reports), Cline also maintains a **per-bootstrap mapping snapshot** at:
85
86```
87customizations/mappings/<bootstrap_id>.json
88```
89
90This snapshot pairs with the placeholdered profile at
91`customizations/profiles/<bootstrap_id>.json` (which Teacher LLM commits to public
92github). At parse time, NORA's runtime substitution layer reads the snapshot and
93resolves placeholders in the profile's regex strings to real values.
94
95**The `customizations/mappings/` directory is NOT gitignored**. The contents are
96committed and pushed to the **company-internal** git remote so every team member
97shares one source of truth for the mappings. The trust boundary against the **public**
98mirror (`github.com`) is the work-PC pre-push hook installed by
99`~/work/utils/git-sync/sync-work.sh`: any `git push` whose remote URL is `github.com`
100is rejected unless `NORA_ALLOW_PUBLIC_PUSH=1` is set explicitly (used only for
101audited force-pushes such as history rewrites).
102
103You own this directory. `cline-playbooks/bootstrap.md` Step 8 specifies the write
104operation; `cline-playbooks/mapping.md` documents the on-disk shape and the live-vs-
105snapshot distinction. The directory IS suitable for git tracking — staging and
106committing mapping files is part of the normal team-sync flow. The hook (not
107`.gitignore`) is what keeps them off the public mirror.
108
@@ −1 +1 @@
1−# Your role: on-prem student to a Teacher LLM
1+# Content safety: nothing proprietary leaves the on-prem machine
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 reports off your screen and hand-types into Teacher LLM. Teacher LLM must NEVER
4+see verbatim corpus content, MNO names, plan IDs, requirement IDs, release codes, or any
5+file path under `<env_dir>/input/`.
76
8−## The standard loop
7+## Redaction protocol
98
9+You maintain a literal-string mapping at `<env_dir>/state/cline-mapping.json`. Apply it
10+forward (real → placeholder) before emitting any report, and reverse (placeholder → real)
11+when acting on Teacher LLM's response.
12+
13+**Mapping schema**:
14+
15+```json
16+{
17+ "version": 1,
18+ "mappings": {
19+ "<real-string>": "<placeholder>"
20+ }
21+}
1022 ```
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−```
2123
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.
24+**Placeholder format** — angle-bracketed, category-prefixed, stable index:
2425
25−## What you do
26+| Category | Pattern | Example |
27+|---|---|---|
28+| MNO short prefix | `<MNO{N}>` | `VZ` → `<MNO0>` |
29+| MNO alias | `<MNO{N}_ALIAS>` | `VZW` → `<MNO0_ALIAS>` |
30+| MNO full name | `<MNO{N}_NAME>` | `Verizon` → `<MNO0_NAME>` |
31+| Plan ID | `<PLAN{N}>` | `LTEAT` → `<PLAN0>` |
32+| Plan name | `<PLAN{N}_NAME>` | (use when plan_name differs from plan_id) |
33+| Release | `<REL{N}>` | `OA-baseline` → `<REL0>` |
34+| Requirement ID | `<REQID-{N}>` | `VZ_REQ_LTEAT_45` → `<REQID-0>` |
35+| Standards spec | `<SPEC{N}>` | `3GPP TS 24.301` → keep as-is (public standard, not proprietary) |
2636
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+`{N}` is a stable index — once allocated, never changes. New entries get the next free index.
3738
38−## What you do NOT do
39+Apply substitution **longest-match-first** so `VZ_REQ_LTEAT_45` matches before `VZ`.
3940
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).
41+The mapping playbook (`cline-playbooks/mapping.md`) describes how to seed and grow this
42+file.
4743
48−## Per-session
44+## Hard rules — never include in your report
4945
50−On first conversation each session, run `cline-playbooks/orient.md` to load project context.
51−Then proceed to the task at hand.
46+- Verbatim quotes from any document under `<env_dir>/input/`
47+- Section heading text > 5 words (treat as title-class quoted prose)
48+- Requirement body text (any length)
49+- Acronym definitions in full (the expansion phrase IS corpus content)
50+- Tabular requirement data
51+- Real values for any token in the mapping (always emit the placeholder)
52+- Un-redacted file paths under `<env_dir>/input/<...>` (the path components are MNO/RELEASE/PLAN)
53+
54+## OK to include (after redaction)
55+
56+- Counts, percentages, ratios
57+- Generic regex patterns — `^\d+(?:\.\d+)+\s+\S` is fine
58+- Format-class observations — `89% of headings are numbered N.N.N`
59+- Coverage stats — `rule catches 487/503`
60+- Counts of misses by severity — `HIGH=96%, MED=3%, LOW=0.1%`
61+- Source code paths inside the repo — `core/src/parser/structural_parser.py:1243`
62+ (those are repo paths, not corpus)
63+- Public standards references — `3GPP TS 24.301, Section 5.5.1.2.6` (public knowledge)
64+- Domain terminology — `ATTACH`, `EMM`, `NAS` (3GPP standard terms)
65+
66+## Borderline cases
67+
68+A regex that ORs corpus-specific values is suspect: `(ATTACH|DETACH|FOO)` is fine if all
69+three are public 3GPP terms; not fine if `FOO` is a customer-specific keyword. When unsure,
70+add `FOO` to the mapping and emit the redacted form.
71+
72+When unsure in general: ask the user. Default to redaction.
73+
74+## What this protects against
75+
76+A passing observer of the user's hand-typed reports — and Teacher LLM itself, which logs
77+conversations — never sees any string that uniquely identifies a customer, document,
78+release, or specific requirement. Patterns and counts are sufficient for Teacher LLM to
79+update code; concrete values stay on-prem.
80+
81+## Mapping snapshot location [D-062]
82+
83+Beyond the live `<env_dir>/state/cline-mapping.json` (forward redaction for outgoing
84+reports), Cline also maintains a **per-bootstrap mapping snapshot** at:
85+
86+```
87+customizations/mappings/<bootstrap_id>.json
88+```
89+
90+This snapshot pairs with the placeholdered profile at
91+`customizations/profiles/<bootstrap_id>.json` (which Teacher LLM commits to public
92+github). At parse time, NORA's runtime substitution layer reads the snapshot and
93+resolves placeholders in the profile's regex strings to real values.
94+
95+**The `customizations/mappings/` directory is NOT gitignored**. The contents are
96+committed and pushed to the **company-internal** git remote so every team member
97+shares one source of truth for the mappings. The trust boundary against the **public**
98+mirror (`github.com`) is the work-PC pre-push hook installed by
99+`~/work/utils/git-sync/sync-work.sh`: any `git push` whose remote URL is `github.com`
100+is rejected unless `NORA_ALLOW_PUBLIC_PUSH=1` is set explicitly (used only for
101+audited force-pushes such as history rewrites).
102+
103+You own this directory. `cline-playbooks/bootstrap.md` Step 8 specifies the write
104+operation; `cline-playbooks/mapping.md` documents the on-disk shape and the live-vs-
105+snapshot distinction. The directory IS suitable for git tracking — staging and
106+committing mapping files is part of the normal team-sync flow. The hook (not
107+`.gitignore`) is what keeps them off the public mirror.
52108
