Remove notes

Signed-off-by: Tushar Goel <tushar.goel.dav@gmail.com>

Author: TG1999

website/docs/architecture_decision/0001_vulnerabilitiy_triaging_rules.md

@@ -56,8 +56,7 @@ We used this idea for our **outcomes**:
 
 **Main question**
 
-> How do we write and run triage policy inside DejaCode,
-> and not build a second big system?
+How do we write and run triage policy inside DejaCode, and not build a second big system?
 
 ---
 
@@ -274,10 +273,6 @@ Both go to the same DB objects.
 - Built-in packs ship as YAML.
 - Users can copy or extend them and keep their own rulesets in the UI.
 
-> **Note:** YAML loader already exists (`triage_rules/loader.py`).
-> Web UI and Django admin are **not** ready yet.
-> Models are still the shared source of truth.
-
 ---
 
 ## When triage runs
@@ -302,14 +297,6 @@ A daily job runs triage again for products that need it.
 
 This also catches external updates even if nobody edited the product that day:
 
-- scores
-- KEV / EPSS
-- delayed sync
-
-> **Note:** No signals, Celery tasks, or schedules in `triage_rules` yet.
-> The engine can be called today.
-> Triggers + daily job are the agreed design.
-
 ---
 
 ## Supported actions (labels) and where they apply
@@ -353,17 +340,6 @@ Each label always applies to **packages** or to the **product**.
 (not every package in the product by default)
 - **Product actions** → the **product** we evaluated
 
-> **Note:** In code today, `TriageDecision.ACTION_CHOICES` only has:
->
-> - `upgrade`
-> - `downgrade`
-> - `reachability`
-> - `forensics`
->
-> The tables above are the **agreed full list**.
-> Still needed: model choices, loader checks, affected-package results,
-> notify audiences.
-
 ---
 
 ## Chosen design (engine and models)