WIP: Staged all changes
This commit is contained in:
@@ -1,38 +1,4 @@
|
||||
# 📁 BUNDLE: Engineering Prompting & GRACE Methodology
|
||||
**Context Transfer Protocol for LLM Agents**
|
||||
|
||||
## 1. Фундаментальная Парадигма (The "Physics" of LLMs)
|
||||
Мы отказываемся от антропоморфного подхода ("диалог с помощником") в пользу инженерного подхода ("программирование семантического процессора").
|
||||
|
||||
* **Трансформер = GNN (Graph Neural Network):** LLM обрабатывает токены как узлы в полносвязном графе. Чтобы модель работала эффективно, мы должны явно задавать топологию этого графа через семантические связи.
|
||||
* **Мышление = Навигация по Состояниям (FSM):** Генерация — это переход между "состояниями веры" (Belief States). Мы управляем этими переходами через Якоря и Контракты.
|
||||
* **Causal Attention & KV Cache:** Модель читает слева-направо. Смысл, обработанный в начале, "замораживается". **Правило:** Контекст и Контракты всегда строго *до* реализации.
|
||||
* **Sparse Attention & Block Processing:** На больших контекстах (100k+) модель работает не с отдельными токенами, а с семантическими сжатиями блоков (чанков). Наша разметка создает идеальные границы для этих блоков, помогая механизму Top-K retrieval.
|
||||
* **Проблема "Семантического Казино":** Без жесткой структуры модель играет в рулетку вероятностей. Мы устраняем это через детерминированные структуры (графы, схемы).
|
||||
* **Проблема "Нейронного Воя" (Neural Howlround):** Самоусиливающиеся ошибки в длинных сессиях. **Решение:** Разделение сессий, жесткие инварианты и использование "суперпозиции" (анализ вариантов перед решением).
|
||||
|
||||
---
|
||||
|
||||
## 2. Методология GRACE (Framework)
|
||||
Целостная система управления жизненным циклом генерации.
|
||||
|
||||
* **G (Graph):** Глобальная карта проекта. Определяет связи (`DEPENDS_ON`, `CALLS`) между модулями. Служит картой для навигации внимания.
|
||||
* **R (Rules):** Инварианты и ограничения (Безопасность, Стек, Паттерны).
|
||||
* **A (Anchors):** Система навигации внутри кода.
|
||||
* *Открывающий якорь:* Задает контекст.
|
||||
* *Замыкающий якорь:* **Аккумулятор семантики**. Критически важен для RAG-систем (Cursor, GraphRAG), так как "вбирает" в себя смысл всего блока.
|
||||
* **C (Contracts):** Принцип **Design by Contract (DbC)**. Спецификация (`@PRE`, `@POST`) всегда пишется *до* кода. Реализация обязана содержать проверки (`assert`/`raise`) этих условий.
|
||||
* **E (Evaluation):** Логирование как декларация состояния (`[STATE:Validation]`) и проверка когерентности (`[Coherence:OK]`).
|
||||
|
||||
---
|
||||
|
||||
## 3. Рабочий Протокол: GRACE-Py v3.1 (Strict Edition)
|
||||
Это стандарт синтаксиса, к которому мы пришли. Он минимизирует "шум" (интерференцию с XML), использует нативные для Python токены (`def`) и убирает ролевую шелуху.
|
||||
|
||||
**Скопируйте этот блок в System Prompt новой LLM:**
|
||||
|
||||
```markdown
|
||||
# SYSTEM STANDARD: GRACE-Py CODE GENERATION PROTOCOL
|
||||
# SYSTEM STANDARD: CODE GENERATION PROTOCOL
|
||||
|
||||
**OBJECTIVE:** Generate Python code that strictly adheres to the Semantic Coherence standards defined below. All output must be machine-readable, fractal-structured, and optimized for Sparse Attention navigation.
|
||||
|
||||
@@ -62,8 +28,9 @@ Code must be wrapped in semantic anchors using square brackets to minimize token
|
||||
|
||||
---
|
||||
|
||||
## III. FILE STRUCTURE STANDARD (Module Header)
|
||||
## III. FILE STRUCTURE STANDARD
|
||||
|
||||
### 1. Python Module Header
|
||||
Every `.py` file starts with a Module definition.
|
||||
|
||||
```python
|
||||
@@ -87,6 +54,29 @@ Every `.py` file starts with a Module definition.
|
||||
# [/DEF:module_name]
|
||||
```
|
||||
|
||||
### 2. Svelte Component Header
|
||||
Every `.svelte` file starts with a Component definition inside an HTML comment.
|
||||
|
||||
```html
|
||||
<!--
|
||||
[DEF:ComponentName:Component]
|
||||
@SEMANTICS: [keywords]
|
||||
@PURPOSE: [Primary responsibility]
|
||||
@LAYER: [UI/State/Layout]
|
||||
@RELATION: [Child components, Stores, API]
|
||||
|
||||
@PROPS:
|
||||
- name: type - description
|
||||
@EVENTS:
|
||||
- name: payload_type - description
|
||||
@INVARIANT: [Immutable UI rule]
|
||||
-->
|
||||
<script>
|
||||
// ...
|
||||
</script>
|
||||
<!-- [/DEF:ComponentName] -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## IV. FUNCTION & CLASS CONTRACTS (DbC)
|
||||
@@ -107,7 +97,7 @@ Contracts are the **Source of Truth**.
|
||||
#
|
||||
# @RELATION: [Graph connections]
|
||||
def func_name(...):
|
||||
# 1. Runtime check of @PRE (Assertions)
|
||||
# 1. Runtime check of @PRE
|
||||
# 2. Logic implementation
|
||||
# 3. Runtime check of @POST
|
||||
pass
|
||||
@@ -131,14 +121,4 @@ Logs define the agent's internal state for debugging and coherence checks.
|
||||
2. **Define Structure:** Generate `[DEF]` anchors and Contracts FIRST.
|
||||
3. **Implement Logic:** Write code satisfying Contracts.
|
||||
4. **Validate:** If logic conflicts with Contract -> Stop -> Report Error.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Интеграция с RAG (GraphRAG)
|
||||
Как этот код используется инструментами (например, Cursor):
|
||||
|
||||
1. **Индексация:** RAG-система парсит теги `[DEF]`, `[/DEF]` и `@RELATION`.
|
||||
2. **Построение Графа:** На основе `@RELATION` и `@DEPENDS_ON` строится граф знаний проекта.
|
||||
3. **Вектор-Аккумулятор:** Замыкающий тег `[/DEF:func_name]` используется как точка для создания эмбеддинга всего блока. Это позволяет находить функцию не только по имени, но и по её внутренней логике.
|
||||
4. **Поиск:** При запросе "Где логика авторизации?" система находит модуль по тегу `@SEMANTICS: auth` и переходит к конкретным функциям по графу.
|
||||
|
||||
Reference in New Issue
Block a user