FrameCode VibeWork - Complete Framework Guide

1.1 Visão geral

FrameCode VibeWork é um framework de desenvolvimento assistido por IA orientado por documentação, criado para reduzir perda de contexto, controlar escopo e padronizar execução técnica entre humanos e agentes.

O que ele é

Um framework de governança operacional e técnica.
Uma estrutura de memória incremental baseada em Markdown.
Um padrão de trabalho com rastreabilidade completa por versão.

O que ele não é

Não é um framework de frontend/backend com runtime próprio.
Não substitui Git, revisão ou decisão arquitetural humana.
Não depende de scripts automáticos para governança.

1.2 Problema resolvido

Sessões com IA sofrem com perda de contexto, repetição de erros e mudanças sem trilha de auditoria. O framework estrutura esse processo para tornar a execução previsível e auditável.

Dor comum	Resposta no framework
Contexto se perde entre sessões	Síntese AICC em `wiki/sessions/` e ingestão seletiva.
Escopo muda sem controle	Regra obrigatória de plano em `Plans/` antes de qualquer modificação.
Mudanças sem histórico claro	Changelog versionado em `changelogs/Vx.y.z.md`.
Conhecimento técnico disperso	LLM Wiki estruturada em `wiki/` (patterns, decisions, releases, sessions).

1.3 Ciclo de funcionamento

Fluxograma operacional do framework (mesma lógica do README), mostrando o ciclo completo de execução e retroalimentação de contexto.

Fase 0: BriefingDefinição inicial de escopo, contexto e objetivos do projeto.

Manifesto e escopoConsolidação da base oficial em documentos de identidade e limite funcional.

Plano de alteraçãoRegistro de prioridade, risco, critérios de aceite e validação antes de editar.

Implementação assistida por IAExecução limitada ao escopo aprovado no plano.

Changelog e versionamentoRastreabilidade formal das mudanças em arquivos versionados.

Auditoria e validaçãoValidação proporcional ao risco e revisão dos impactos.

Wiki / memória técnicaCompressão de contexto (AICC) e registro de conhecimento reutilizável.

Documentação públicaPublicação no Wiki e no GitHub Pages para consumo humano.

Contexto acumulado alimenta o próximo plano de alteração.

Regra central: nenhuma alteração funcional, visual, estrutural ou documental deve ocorrer sem plano correspondente.

2.1 Arquitetura documental

A aplicação funciona como uma malha de documentos com responsabilidades explícitas.

Camada	Documento / Pasta	Responsabilidade
Operação	`AGENTS.md`	Guia principal de execução para humanos e IA.
Identidade	`MANIFEST.md`	Estado oficial, escopo resumido e riscos principais.
Mudanças	`Plans/`	Ciclo de vida de cada alteração.
Versões	`changelogs/`	Registro formal por versão.
Memória	`wiki/`	Conhecimento técnico incremental e navegável.
Padrões IA	`skills/`	Checklists de alta densidade carregados sob demanda.
Templates	`governance/`	Estruturas vazias reutilizáveis para novos projetos.

2.2 Governança por planos

Fluxo obrigatório

Criar plano em Plans/pending/.
Mover para Plans/in_progress/ ao iniciar.
Executar somente o escopo aprovado.
Atualizar changelog da versão.
Fechar plano em Plans/completed/ ou discontinued/.

Campos mínimos do plano

Prioridade P1..P5 e risco R1..R5
Versão atual e esperada
Critérios de aceite
Plano de testes
Status e evidências de validação

2.3 Versionamento e release

O framework segue Vx.y.z e exige changelog para toda mudança em arquivo versionado.

Major: quebra de compatibilidade, mudança arquitetural ampla.
Minor: novas capacidades e fluxos relevantes.
Patch: correções e melhorias documentais/processuais.

Estados de release: in_preparation, in_validation, published, canceled.

Uma versão só pode ser published quando os planos citados estiverem em Plans/completed/ e as validações estiverem registradas.

2.4 IA, AICC e ASE

AICC (compressão de contexto)

Gera síntese cronológica por sessão em wiki/sessions/S*.md.
Reduz custo de tokens com handoff estruturado.
Permite retomar trabalho sem reprocessar todo o repositório.

ASE (motor de habilidades)

Carrega skills sob demanda (JIT), não no prompt inicial.
Inclui habilidades de release, lint wiki, commits e formatação.
Melhora consistência e reduz ruído de contexto.

Referências: AI.md, CONTEXT_MAP.md, skills/README.md, wiki/schema.md.

2.5 Modelos locais: parâmetros e janela de contexto

Recomendação prática para uso do framework com modelos locais, com base no volume documental do próprio FCVW e no custo de contexto por sessão.

Faixa	Parâmetros	Janela de contexto	Uso recomendado no framework
Mínimo operacional	`7B-8B`	`16k`	Correções curtas, ajustes em 1-3 arquivos, tarefas objetivas com contexto enxuto.
Recomendado geral	`14B-32B`	`32k-64k`	Fluxo completo com plano + changelog + wiki, revisões médias e múltiplos documentos.
Alta confiabilidade	`32B-70B+`	`64k-128k`	Refatorações amplas, auditorias, releases complexos e sessões longas sem perda de coerência.

Para operar com estabilidade, reserve folga de contexto de 40% a 60% para histórico, diffs e respostas longas.
No FCVW, a carga inicial varia por tipo de sessão; sem compressão pode chegar a ~8.5k tokens, então 16k é o piso seguro para uso real.
Para desempenho consistente em tarefas de governança e escrita técnica estruturada, a faixa 14B+ tende a reduzir retrabalho.

Inferência aplicada ao framework: estas faixas foram definidas a partir dos cenários de ingestão e ciclo operacional documentados no próprio repositório.

3.1 Segurança e dados

Não versionar credenciais, dados privados e artefatos temporários.
Validar path traversal em qualquer leitura/escrita de caminhos dinâmicos.
Manter .env e variantes fora do versionamento (com .env.example permitido).
Registrar limitações ou riscos residuais ao fechar planos.

3.2 Validação e auditoria

A validação é proporcional ao risco e sempre precisa ser registrada com evidência.

Risco	Nível mínimo esperado
`R1` / `R2`	Verificações locais + revisão de links/consistência.
`R3`	Validação de fluxos compartilhados e regressão local.
`R4` / `R5`	Validações completas com foco em segurança, dados e rollback.

3.3 Publicação no GitHub Pages

Esta página foi desenhada para publicação estática em docs/index.html.

Acesse Settings > Pages no repositório.
Em Build and deployment, selecione Deploy from a branch.
Escolha a branch de publicação (normalmente main) e a pasta /docs.
Salve e aguarde o deploy automático do GitHub Pages.

URL esperada: https://sistema2d.github.io/FrameCode-VibeWork/.

3.4 Início rápido

Abra o repositório em uma IDE com IA.
No prompt, mencione AGENTS.md e peça diretamente sua tarefa: Siga AGENTS.md e: <sua solicitação>.
A IA deve ler os arquivos necessários, aplicar o fluxo de plano, implementar, validar e registrar changelog/wiki conforme o framework.
Revise o resultado e publique as mudanças para atualização do GitHub Pages.

Resultado prático: o processo fica quase automático para humanos, mantendo governança e rastreabilidade técnica.

1.1 Overview

FrameCode VibeWork is a documentation-first framework for AI-assisted development, designed to reduce context loss, enforce scope control, and standardize technical execution across humans and agents.

What it is

An operational and technical governance framework.
An incremental memory system based on Markdown.
A work model with full version-level traceability.

What it is not

Not a frontend/backend runtime framework.
Not a replacement for Git review or human architectural decisions.
Not dependent on automation scripts for governance.

1.2 Problem solved

AI sessions often drift, repeat mistakes, and apply changes without audit trails. This framework structures the process to keep execution predictable and verifiable.

Common pain	Framework response
Session context gets lost	AICC session synthesis in `wiki/sessions/` plus selective ingestion.
Scope changes without control	Mandatory plan rule in `Plans/` before any modification.
Changes with unclear history	Versioned changelog in `changelogs/Vx.y.z.md`.
Scattered technical knowledge	Structured LLM Wiki in `wiki/` (patterns, decisions, releases, sessions).

1.3 Operating lifecycle

Official framework flowchart (aligned with README), showing the end-to-end operational cycle and context feedback loop.

Phase 0: BriefingInitial definition of project scope, context, and objectives.

Manifest and scopeBaseline official documents define identity and functional boundaries.

Change planPriority, risk, acceptance criteria, and validation are set before edits.

AI-assisted implementationExecution remains strictly limited to approved plan scope.

Changelog and versioningFormal traceability for all versioned-file modifications.

Audit and validationRisk-proportional testing and impact review.

Wiki / technical memoryAICC context compression and reusable knowledge capture.

Public documentationPublication to Wiki and GitHub Pages for human consumption.

Accumulated context feeds the next change plan cycle.

Core rule: no functional, visual, structural, or document change without a corresponding plan.

2.1 Document architecture

The application operates as a documentation mesh with explicit responsibilities.

Layer	File / Directory	Responsibility
Operations	`AGENTS.md`	Primary execution guide for humans and AI.
Identity	`MANIFEST.md`	Official state, summarized scope, and key risks.
Change control	`Plans/`	Lifecycle of each change.
Version history	`changelogs/`	Formal per-version record.
Memory	`wiki/`	Incremental and navigable technical knowledge.
AI patterns	`skills/`	High-density checklists loaded on demand.
Templates	`governance/`	Reusable empty structures for new projects.

2.2 Plan-driven governance

Mandatory flow

Create plan in Plans/pending/.
Move to Plans/in_progress/ when work starts.
Execute only approved scope.
Update version changelog.
Close in Plans/completed/ or discontinued/.

Minimum plan fields

Priority P1..P5 and risk R1..R5
Current and expected version
Acceptance criteria
Test plan
Status and validation evidence

2.3 Versioning and release

The framework follows Vx.y.z and requires changelog updates for every versioned-file modification.

Major: compatibility breaks and broad architecture changes.
Minor: relevant new capabilities and flows.
Patch: fixes and documentation/process improvements.

Release states: in_preparation, in_validation, published, canceled.

A version can be marked published only when cited plans are in Plans/completed/ and validations are documented.

2.4 AI, AICC and ASE

AICC (context compression)

Creates chronological synthesis per session in wiki/sessions/S*.md.
Reduces token cost via structured handoff.
Allows fast continuation without re-reading the entire repository.

ASE (skills engine)

Loads skills on demand (JIT), never in the initial prompt.
Includes release, wiki lint, commit, and formatting skills.
Improves consistency while preserving context window.

References: AI.md, CONTEXT_MAP.md, skills/README.md, wiki/schema.md.

2.5 Local models: parameters and context window

Practical sizing guidance for running this framework with local models, based on FCVW's own document load profile and session context volume.

Tier	Parameters	Context window	Recommended framework usage
Minimum operational	`7B-8B`	`16k`	Short fixes, small edits in 1-3 files, narrow prompts with compact context.
General recommended	`14B-32B`	`32k-64k`	Full flow with plan + changelog + wiki, medium reviews, and multi-document sessions.
High reliability	`32B-70B+`	`64k-128k`	Large refactors, audits, complex releases, and long sessions with stronger coherence.

For stable operation, keep 40% to 60% free context headroom for history, diffs, and long completions.
In FCVW, initial session ingestion can reach ~8.5k tokens without compression, so 16k is the practical floor.
For consistent governance-heavy writing and structured outputs, 14B+ generally reduces rework.

Framework inference: these thresholds are derived from FCVW's documented ingestion scenarios and operational cycle.

3.1 Security and data

Do not version credentials, private data, or temporary artifacts.
Validate path traversal on any dynamic path read/write workflow.
Keep .env and variants out of version control (allow .env.example only).
Record limitations and residual risk when closing plans.

3.2 Validation and audit

Validation is risk-proportional and must be recorded with evidence.

Risk	Minimum expected level
`R1` / `R2`	Local checks plus links/consistency review.
`R3`	Shared-flow validation and local regression checks.
`R4` / `R5`	Complete validations focused on security, data, and rollback.

3.3 GitHub Pages publishing

This page is designed for static publishing at docs/index.html.

Go to repository Settings > Pages.
Under Build and deployment, choose Deploy from a branch.
Select the publishing branch (usually main) and /docs folder.
Save and wait for GitHub Pages deployment.

Expected URL: https://sistema2d.github.io/FrameCode-VibeWork/.

3.4 Quick start

Open the repository in an AI-enabled IDE.
In your prompt, mention AGENTS.md and directly request the task: Follow AGENTS.md and: <your request>.
The AI should read required files, execute the plan workflow, implement, validate, and update changelog/wiki records.
Review output and publish changes so GitHub Pages updates automatically.

Practical result: humans stay focused on intent while the framework process is guided almost automatically.

1.1 Resumen general

FrameCode VibeWork es un framework guiado por documentación para desarrollo asistido por IA, diseñado para reducir pérdida de contexto, controlar alcance y estandarizar la ejecución técnica entre humanos y agentes.

Qué es

Un framework de gobernanza operativa y técnica.
Un sistema de memoria incremental basado en Markdown.
Un modelo de trabajo con trazabilidad completa por versión.

Qué no es

No es un framework de frontend/backend con runtime propio.
No reemplaza Git, revisiones ni decisiones arquitectónicas humanas.
No depende de scripts automáticos para gobernanza.

1.2 Problema resuelto

Las sesiones con IA suelen perder contexto, repetir errores y ejecutar cambios sin trazabilidad clara. El framework estructura ese proceso para mantenerlo predecible y auditable.

Problema común	Respuesta del framework
Contexto perdido entre sesiones	Síntesis AICC en `wiki/sessions/` + ingestión selectiva.
Cambios sin control de alcance	Plan obligatorio en `Plans/` antes de cualquier modificación.
Historial técnico difuso	Changelog versionado en `changelogs/Vx.y.z.md`.
Conocimiento disperso	LLM Wiki estructurada en `wiki/` (patterns, decisions, releases, sessions).

1.3 Ciclo operativo

Flujograma oficial del framework (alineado con README), mostrando el ciclo completo de operación y realimentación de contexto.

Fase 0: BriefingDefinición inicial del alcance, contexto y objetivos del proyecto.

Manifiesto y alcanceBase documental oficial de identidad y límites funcionales.

Plan de cambioPrioridad, riesgo, criterios de aceptación y validaciones antes de editar.

Implementación asistida por IAEjecución limitada estrictamente al alcance aprobado.

Changelog y versionadoTrazabilidad formal de toda modificación en archivos versionados.

Auditoría y validaciónPruebas proporcionales al riesgo y revisión de impactos.

Wiki / memoria técnicaCompresión de contexto AICC y registro de conocimiento reutilizable.

Documentación públicaPublicación en Wiki y GitHub Pages para consumo humano.

El contexto acumulado alimenta el siguiente ciclo de planificación.

Regla central: no debe existir cambio funcional, visual, estructural ni documental sin un plan correspondiente.

2.1 Arquitectura documental

La aplicación opera como una malla documental con responsabilidades explícitas.

Capa	Documento / Carpeta	Responsabilidad
Operación	`AGENTS.md`	Guía principal de ejecución para humanos e IA.
Identidad	`MANIFEST.md`	Estado oficial, alcance resumido y riesgos clave.
Cambios	`Plans/`	Ciclo de vida de cada modificación.
Versiones	`changelogs/`	Registro formal por versión.
Memoria	`wiki/`	Conocimiento técnico incremental y navegable.
Patrones IA	`skills/`	Checklists de alta densidad cargados bajo demanda.
Plantillas	`governance/`	Estructuras vacías reutilizables para nuevos proyectos.

2.2 Gobernanza por planes

Flujo obligatorio

Crear plan en Plans/pending/.
Mover a Plans/in_progress/ al iniciar.
Ejecutar solo el alcance aprobado.
Actualizar changelog de versión.
Cerrar en Plans/completed/ o discontinued/.

Campos mínimos del plan

Prioridad P1..P5 y riesgo R1..R5
Versión actual y versión esperada
Criterios de aceptación
Plan de pruebas
Estado y evidencias de validación

2.3 Versionado y release

Sigue Vx.y.z y exige changelog para toda modificación de archivo versionado.

Major: ruptura de compatibilidad y cambios arquitectónicos amplios.
Minor: nuevas capacidades o flujos relevantes.
Patch: correcciones y mejoras de documentación/proceso.

Estados de release: in_preparation, in_validation, published, canceled.

Una versión solo puede marcarse como published cuando los planes citados estén en Plans/completed/ y las validaciones estén registradas.

2.4 IA, AICC y ASE

AICC (compresión de contexto)

Genera síntesis cronológica por sesión en wiki/sessions/S*.md.
Reduce costo de tokens mediante handoff estructurado.
Permite retomar trabajo sin releer todo el repositorio.

ASE (motor de habilidades)

Carga skills bajo demanda (JIT), nunca en el prompt inicial.
Incluye habilidades de release, wiki lint, commits y formato.
Mejora consistencia preservando la ventana de contexto.

Referencias: AI.md, CONTEXT_MAP.md, skills/README.md, wiki/schema.md.

2.5 Modelos locales: parámetros y ventana de contexto

Guía práctica para operar el framework con modelos locales, basada en el volumen documental de FCVW y el costo de contexto por sesión.

Nivel	Parámetros	Ventana	Uso recomendado en el framework
Mínimo operativo	`7B-8B`	`16k`	Correcciones cortas, ajustes en 1-3 archivos y tareas puntuales.
Recomendado general	`14B-32B`	`32k-64k`	Flujo completo con plan + changelog + wiki y revisiones medianas.
Alta confiabilidad	`32B-70B+`	`64k-128k`	Refactors amplios, auditorías, releases complejos y sesiones largas.

Para operar con estabilidad, reserva 40% a 60% de contexto libre para historial, diffs y respuestas largas.
En FCVW, la ingesta inicial puede llegar a ~8.5k tokens sin compresión, por eso 16k es el piso práctico.
Para tareas largas y estructuradas, 14B+ suele reducir retrabajo.

Inferencia aplicada al framework: estos rangos se definieron a partir de escenarios documentados de ingesta y ciclo operativo.

3.1 Seguridad y datos

No versionar credenciales, datos privados ni artefactos temporales.
Validar path traversal en cualquier lectura/escritura de rutas dinámicas.
Mantener .env y variantes fuera del versionado (permitir solo .env.example).
Registrar limitaciones y riesgos residuales al cerrar planes.

3.2 Validación y auditoría

Las validaciones deben ser proporcionales al riesgo y registradas con evidencia.

Riesgo	Nivel mínimo esperado
`R1` / `R2`	Comprobaciones locales + revisión de enlaces/consistencia.
`R3`	Validación de flujos compartidos y chequeos de regresión local.
`R4` / `R5`	Validaciones completas con foco en seguridad, datos y rollback.

3.3 Publicación en GitHub Pages

Esta página está diseñada para publicación estática en docs/index.html.

Accede a Settings > Pages del repositorio.
En Build and deployment, selecciona Deploy from a branch.
Elige la branch de publicación (normalmente main) y la carpeta /docs.
Guarda y espera el despliegue automático de GitHub Pages.

URL esperada: https://sistema2d.github.io/FrameCode-VibeWork/.

3.4 Inicio rápido

Abre el repositorio en una IDE con IA.
En el prompt, menciona AGENTS.md y pide tu tarea de forma directa: Sigue AGENTS.md y: <tu solicitud>.
La IA debe leer los archivos necesarios, ejecutar el flujo de plan, implementar, validar y actualizar changelog/wiki.
Revisa el resultado y publica cambios para actualizar GitHub Pages.

Resultado práctico: la persona se enfoca en el objetivo y el framework guía la ejecución casi automáticamente.

1.1 Überblick

FrameCode VibeWork ist ein dokumentationszentriertes Framework für KI-gestützte Entwicklung. Es reduziert Kontextverlust, steuert den Scope und standardisiert die technische Ausführung zwischen Menschen und KI-Agenten.

Was es ist

Ein Framework für operative und technische Governance.
Ein inkrementelles Wissenssystem auf Markdown-Basis.
Ein Arbeitsmodell mit vollständiger Nachvollziehbarkeit pro Version.

Was es nicht ist

Kein Frontend-/Backend-Framework mit eigenem Runtime-Stack.
Kein Ersatz für Git-Review oder menschliche Architekturentscheidungen.
Keine Governance, die von Automatisierungsskripten abhängt.

1.2 Gelöstes Problem

KI-Sitzungen verlieren häufig Kontext, wiederholen Fehler und erzeugen Änderungen ohne klare Auditspur. Das Framework strukturiert diesen Ablauf, damit die Ausführung vorhersehbar und prüfbar bleibt.

Häufiges Problem	Framework-Lösung
Kontextverlust zwischen Sitzungen	AICC-Synthesen in `wiki/sessions/` plus selektive Ingestion.
Scope-Drift ohne Steuerung	Verbindliche Planregel in `Plans/` vor jeder Änderung.
Unklare Änderungshistorie	Versioniertes Changelog in `changelogs/Vx.y.z.md`.
Verteiltes technisches Wissen	Strukturierte LLM-Wiki in `wiki/` (patterns, decisions, releases, sessions).

1.3 Betriebsablauf

Offizielles Framework-Flussdiagramm (mit README abgestimmt), das den kompletten Zyklus inklusive Kontext-Feedback zeigt.

Phase 0: BriefingInitiale Definition von Scope, Kontext und Projektzielen.

Manifest und ScopeOffizielle Basisdokumente für Identität und funktionale Grenzen.

ÄnderungsplanPriorität, Risiko, Akzeptanzkriterien und Validierung vor der Umsetzung.

KI-gestützte ImplementierungAusführung bleibt strikt innerhalb des genehmigten Planumfangs.

Changelog und VersionierungFormale Nachvollziehbarkeit für alle Änderungen in versionierten Dateien.

Audit und ValidierungRisikoproportionale Tests und Wirkungsprüfung.

Wiki / technisches GedächtnisAICC-Kontextkompression und Erfassung wiederverwendbaren Wissens.

Öffentliche DokumentationPublikation in Wiki und GitHub Pages für menschliche Nutzung.

Der akkumulierte Kontext speist den nächsten Planungszyklus.

Kernregel: keine funktionale, visuelle, strukturelle oder dokumentarische Änderung ohne zugehörigen Plan.

2.1 Dokumentenarchitektur

Die Anwendung arbeitet als Dokumentationsnetz mit klaren Verantwortlichkeiten.

Ebene	Datei / Verzeichnis	Verantwortung
Betrieb	`AGENTS.md`	Zentrale Ausführungsanleitung für Menschen und KI.
Identität	`MANIFEST.md`	Offizieller Status, zusammengefasster Scope und Hauptrisiken.
Änderungen	`Plans/`	Lebenszyklus jeder Änderung.
Versionen	`changelogs/`	Formales Protokoll pro Version.
Wissen	`wiki/`	Inkrementelles und navigierbares technisches Wissen.
KI-Standards	`skills/`	High-Density-Checklisten, bei Bedarf geladen.
Vorlagen	`governance/`	Wiederverwendbare leere Strukturen für neue Projekte.

2.2 Planbasierte Governance

Verbindlicher Ablauf

Plan in Plans/pending/ erstellen.
Zum Start nach Plans/in_progress/ verschieben.
Nur den freigegebenen Scope umsetzen.
Versions-Changelog aktualisieren.
In Plans/completed/ oder discontinued/ abschließen.

Mindestfelder des Plans

Priorität P1..P5 und Risiko R1..R5
Aktuelle und erwartete Version
Akzeptanzkriterien
Testplan
Status und Validierungsnachweise

2.3 Versionierung und Release

Folgt Vx.y.z und verlangt Changelog-Updates für jede versionierte Dateiänderung.

Major: Kompatibilitätsbrüche und breite Architekturänderungen.
Minor: relevante neue Fähigkeiten und Abläufe.
Patch: Korrekturen sowie Prozess-/Dokumentationsverbesserungen.

Release-Status: in_preparation, in_validation, published, canceled.

Eine Version darf nur als published markiert werden, wenn referenzierte Pläne in Plans/completed/ liegen und Validierungen dokumentiert sind.

2.4 KI, AICC und ASE

AICC (Kontextkompression)

Erzeugt chronologische Sitzungssynthesen in wiki/sessions/S*.md.
Senkt Token-Kosten durch strukturierten Handoff.
Ermöglicht schnelle Fortsetzung ohne erneutes Lesen des ganzen Repos.

ASE (Skills Engine)

Lädt Skills nur bei Bedarf (JIT), nie im initialen Prompt.
Enthält Skills für Release, Wiki-Lint, Commits und Formatierung.
Erhöht Konsistenz bei gleichzeitiger Schonung des Kontextfensters.

Referenzen: AI.md, CONTEXT_MAP.md, skills/README.md, wiki/schema.md.

2.5 Lokale Modelle: Parameter und Kontextfenster

Praktische Größenempfehlungen für lokale Modelle im Framework, basierend auf FCVW-Dokumentlast und Sitzungs-Kontextvolumen.

Stufe	Parameter	Kontextfenster	Empfohlene Framework-Nutzung
Minimaler Betrieb	`7B-8B`	`16k`	Kurze Fixes, kleine Änderungen in 1-3 Dateien, enge Aufgabenstellung.
Allgemein empfohlen	`14B-32B`	`32k-64k`	Vollständiger Ablauf mit Plan + Changelog + Wiki und mittleren Reviews.
Hohe Zuverlässigkeit	`32B-70B+`	`64k-128k`	Große Refactorings, Audits, komplexe Releases und lange Sitzungen.

Für stabilen Betrieb 40% bis 60% Kontextreserve für Verlauf, Diffs und lange Antworten einplanen.
In FCVW kann die Initial-Ingestion ohne Kompression ~8.5k Tokens erreichen, daher ist 16k die praktische Untergrenze.
Für lange strukturierte Aufgaben reduziert 14B+ meist Nacharbeit.

Framework-spezifische Ableitung: Diese Schwellenwerte basieren auf dokumentierten Ingestion-Szenarien und dem operativen Zyklus von FCVW.

3.1 Sicherheit und Daten

Keine Zugangsdaten, privaten Daten oder temporären Artefakte versionieren.
Path Traversal bei allen dynamischen Pfad-Lese-/Schreibabläufen validieren.
.env und Varianten außerhalb der Versionskontrolle halten (.env.example ist erlaubt).
Restliche Einschränkungen und Risiken beim Planabschluss dokumentieren.

3.2 Validierung und Audit

Validierungen sind risikoproportional auszuführen und mit Nachweisen zu dokumentieren.

Risiko	Mindestniveau
`R1` / `R2`	Lokale Checks plus Link-/Konsistenzprüfung.
`R3`	Validierung gemeinsamer Abläufe und lokale Regressionsprüfung.
`R4` / `R5`	Umfassende Validierung mit Fokus auf Sicherheit, Daten und Rollback.

3.3 Veröffentlichung auf GitHub Pages

Diese Seite ist für statische Veröffentlichung unter docs/index.html ausgelegt.

Im Repository zu Settings > Pages gehen.
Unter Build and deployment Deploy from a branch wählen.
Publikations-Branch (meist main) und Ordner /docs auswählen.
Speichern und auf den automatischen GitHub-Pages-Deploy warten.

Erwartete URL: https://sistema2d.github.io/FrameCode-VibeWork/.

3.4 Schnellstart

Repository in einer KI-fähigen IDE öffnen.
Im Prompt AGENTS.md nennen und die Aufgabe direkt stellen: Folge AGENTS.md und: <deine Anfrage>.
Die KI soll benötigte Dateien lesen, den Plan-Workflow ausführen, implementieren, validieren und Changelog/Wiki aktualisieren.
Ergebnis prüfen und Änderungen veröffentlichen, damit GitHub Pages aktualisiert wird.

Praktischer Effekt: Menschen fokussieren sich auf das Ziel, der Framework-Prozess wird nahezu automatisch geführt.

Guia Completo do Framework

1.1 Visão geral

O que ele é

O que ele não é

1.2 Problema resolvido

1.3 Ciclo de funcionamento

2.1 Arquitetura documental

2.2 Governança por planos

Fluxo obrigatório

Campos mínimos do plano

2.3 Versionamento e release

2.4 IA, AICC e ASE

AICC (compressão de contexto)

ASE (motor de habilidades)

2.5 Modelos locais: parâmetros e janela de contexto

3.1 Segurança e dados

3.2 Validação e auditoria

3.3 Publicação no GitHub Pages

3.4 Início rápido

1.1 Overview

What it is

What it is not

1.2 Problem solved

1.3 Operating lifecycle

2.1 Document architecture

2.2 Plan-driven governance

Mandatory flow

Minimum plan fields

2.3 Versioning and release

2.4 AI, AICC and ASE

AICC (context compression)

ASE (skills engine)

2.5 Local models: parameters and context window

3.1 Security and data

3.2 Validation and audit

3.3 GitHub Pages publishing

3.4 Quick start

1.1 Resumen general

Qué es

Qué no es

1.2 Problema resuelto

1.3 Ciclo operativo

2.1 Arquitectura documental

2.2 Gobernanza por planes

Flujo obligatorio

Campos mínimos del plan

2.3 Versionado y release

2.4 IA, AICC y ASE

AICC (compresión de contexto)

ASE (motor de habilidades)

2.5 Modelos locales: parámetros y ventana de contexto

3.1 Seguridad y datos

3.2 Validación y auditoría

3.3 Publicación en GitHub Pages

3.4 Inicio rápido

1.1 Überblick

Was es ist

Was es nicht ist

1.2 Gelöstes Problem

1.3 Betriebsablauf

2.1 Dokumentenarchitektur

2.2 Planbasierte Governance

Verbindlicher Ablauf

Mindestfelder des Plans

2.3 Versionierung und Release

2.4 KI, AICC und ASE

AICC (Kontextkompression)

ASE (Skills Engine)

2.5 Lokale Modelle: Parameter und Kontextfenster

3.1 Sicherheit und Daten

3.2 Validierung und Audit

3.3 Veröffentlichung auf GitHub Pages

3.4 Schnellstart