Skip to content

Platform Reset Standard

Standard ID: ES-PLAT-RESET Scope: Defines the mechanism for resetting platform components via the Release Bundle pipeline.

Field Value
Status Active
Date 2026-07-18
Author Thomas Scola
Scope Platform-wide — architectural reset principles
Authority ES-0001: Bluefly Engineering Standard

1. Ownership Boundaries

Every artifact, repository, and knowledge asset in the Bluefly platform has exactly one owner. Ownership determines who may create, modify, and retire an artifact.

The Repository Authority Model (ES-0001 Section 2) defines four authorities per repository: Development, Source, Deployment, and Recovery. These authorities are distinct and must never be conflated.

The Artifact Production Rule and Documentation Production Rule extend ownership into the knowledge domain — every document and artifact must declare its owner, consumer, lifetime, and authoritative replacement before creation.

For the full ownership model, see: - ES-0001 Section 2: Repository Authority Model - rules/artifact-production-rule.md - rules/documentation-production-rule.md

1.1 Repository Context Model

Every repository is a knowledge artifact, not just a code artifact.

The .agents/context/ directory is first-class repository metadata — equal in authority to composer.json, .gitlab-ci.yml, or Dockerfile. It describes what the repository IS, what it OWNS, what it DOES NOT own, and how to work with it.

Structure

repository/
├── .agents/
│   └── context/
│       ├── INDEX.md           # Entry point, file manifest
│       ├── PROJECT.md         # Purpose, scope, ownership boundaries
│       ├── ARCHITECTURE.md    # Repository architecture (never enterprise)
│       ├── BOUNDARIES.md      # Owns / consumes / implements / never-owns
│       ├── DEPENDENCIES.md    # External systems, APIs, services
│       ├── COMMANDS.md        # Build, test, release, dev commands
│       ├── ROADMAP.md         # Repository-specific future work
│       └── KNOWN_ISSUES.md    # Tech debt, open migrations, concerns

Knowledge Ownership Hierarchy

BluCity-Docs (Organization)
    │
    ├── Engineering Standards
    ├── Architecture Decisions
    ├── Governance
    └── Platform Model
         │
         ▼
Repository Context (.agents/context/)
    │
    ├── PROJECT.md    → What this repo is
    ├── BOUNDARIES.md → What this repo owns
    ├── ARCHITECTURE.md → How this repo works
    └── COMMANDS.md   → How to operate this repo
         │
         ▼
Task Context (Issues, Beads, MRs)
    │
    └── Temporary, never becomes doctrine

Validation Rules

  1. No enterprise architecture in repository context. ARCHITECTURE.md describes the repository's internal architecture. Enterprise architecture lives in BluCity-Docs.
  2. No duplicate ownership. If BluCity-Docs owns a concept, repository context references it — never redefines it.
  3. BOUNDARIES.md is authoritative. The never-owns section is a hard constraint. Agents must not create artifacts that violate it.
  4. INDEX.md is the entry point. Agents must read INDEX.md first. It declares what files exist and what has changed.
  5. Context files are maintained by repository developers. They are not auto-generated. They represent human-curated knowledge about the repository.

Runtime Integration

The reconciliation engine validates repository context files as part of the platform health model:

  • Completeness check: Are all 8 standard files present?
  • Staleness check: Has context been updated within the repository's maintenance window?
  • Boundary violation check: Does the repository's context claim ownership of concepts owned by BluCity-Docs or another repository?
  • Cross-reference check: Do DEPENDENCIES.md entries resolve to real platform services?
  • Consistency check: Does BOUNDARIES.md align with the repository's actual module/service boundaries?

References

  • ES-0001: Bluefly Engineering Standard
  • ADR-0022: Bluefly Runtime Architecture — Gas City as Foundation
  • ADR-0023: Repository Authority Model
  • Bluefly Constitution (governance/constitution.md)
  • Artifact Production Rule (rules/artifact-production-rule.md)
  • Documentation Production Rule (rules/documentation-production-rule.md)