Skip to content

Engineering Guardrails

Jump to bottom
rbiswas5888 edited this page Oct 23, 2026 · 1 revision

Engineering Guardrails

Protect the existing application

Before feature implementation, inspect the repository and document:

  • Current stack, build and test commands
  • Existing document model and rendering approach
  • State management and command paths
  • Save/open/import/export behavior
  • Existing AI/agent and MCP integration
  • Current user-visible features and regression risks

Do not replace working functionality with mockups, placeholders, or dead controls.

Protected integration zone

The supplied master prompt defines the following as protected unless an explicit approval authorizes a change:

  • MCP integration: servers, tool definitions, names, schemas, transports, authentication and registration
  • Existing AI/agent structure: local/offline LLM path, pluggable cloud-agent layer, prompts, orchestration, model routing, fallback logic and configuration
  • Existing agent behavior rules for token/component reuse, unavailable-component notes, and offline/online operation

Required process:

  1. Inventory the protected files, directories, and symbols in docs/frozen-zone.md.
  2. Mark them read-only in the implementation plan.
  3. Add a CI check that detects changes to protected file hashes.
  4. Keep new editor behavior in new modules or adapters.
  5. Preserve exact existing contracts when calling protected functionality.
  6. If a requirement cannot be delivered without changing a protected contract, stop and request approval; propose an adapter-based alternative first.

Implementation method

  1. Audit before coding.
  2. Record current architecture and known gaps.
  3. Agree on the architecture and phased plan.
  4. Make small, reviewable changes.
  5. Prefer existing dependencies and conventions.
  6. Record ambiguous choices in docs/decisions.md.
  7. End each phase with a working demo, tests, changelog, updated parity matrix and protected-zone check.
  8. Report what was tested and what remains incomplete.

Product identity and compatibility

Use DesignForge’s own name, logo, iconography, and visual identity. Reproduce useful interaction conventions, not proprietary implementation or branding. .dforge is DesignForge’s native format; do not claim compatibility with proprietary formats unless an independently verified importer/exporter exists and its scope is documented.

No false completion claims

  • Do not call a placeholder functional.
  • Do not claim performance targets without benchmark results.
  • Do not claim all device presets or file formats are supported without catalog/fixture tests.
  • Do not silently drop unsupported design or prototype semantics during export.
  • Do not treat AI-generated output as trusted merely because it matches a JSON shape; validate it against domain invariants.

Clone this wiki locally