# PFES-ENG-045 — Project Incubation and Repository Admission

**Status:** Binding project-infrastructure method  
**Knowledge Cycle Stages:** Acquire, Preserve, Interpret, Apply

## Purpose

Define how a new Project Frankenstein workstream becomes a recognized project,
how it may operate before a canonical repository exists, and how repository
authority is admitted only after the project is mature enough to sustain it.

## Core rule

**Project admission and repository admission are separate decisions.**

A useful engineering effort may enter PFES as an incubating project before its
name, source tree, hardware design, build process, or validation baseline is
stable. Creating a canonical Git repository is not the first step and is not
automatic.

## Project lifecycle states

| State | Meaning | Repository expectation |
|---|---|---|
| `proposed` | Relevant idea or need, not yet bounded | None |
| `incubating` | Active work with a charter, steward, artifacts, and safety boundaries | Deferred unless already justified |
| `repository_ready` | Scope, source tree, validation baseline, and lifecycle boundary are stable | Candidate repository may be prepared |
| `authority_active` | Reviewed candidate was staged and promoted; authority marker and recovery evidence exist | Canonical repository active |
| `maintenance` | Stable project receiving controlled changes | Canonical repository maintained |
| `archived` | Work preserved but no longer active | Repository or immutable snapshot retained as appropriate |

A project may move backward when scope becomes unstable, safety evidence is
invalidated, or repository boundaries prove incorrect.

## Project-admission gate

A proposed effort becomes `incubating` only when PFES records:

1. a canonical project name and stable identifier;
2. the engineering problem and relation to Project Frankenstein;
3. scope and explicit non-goals;
4. a responsible steward or handoff role;
5. current artifact identities and provenance;
6. safety, destructive-operation, and hardware-risk boundaries;
7. current maturity and known limitations;
8. near-term acceptance gates;
9. repository status, including an explicit reason when deferred;
10. an agent/engineer handoff path.

Admission means the project is recognized and preserved. It does not validate
its technical claims, authorize fabrication, authorize destructive operations,
or activate a repository.

## Incubation rules

During incubation:

- PFES holds the charter, status record, artifact hashes, safety boundaries,
  decisions, and handoff;
- evolving source packages may remain external artifacts while structure is
  unstable;
- every supplied package must be hash-identified and integrity-checked;
- generated outputs and source-of-truth files must be distinguished;
- preliminary footprints, schematics, firmware, and assumptions remain marked
  preliminary until their own gates pass;
- repository creation must not be used to imply maturity;
- destructive capabilities remain disabled until separately authorized and
  validated.

Incubation is not a lesser form of preservation. It is the correct state for a
project whose evidence is useful but whose long-term source boundary is not yet
settled.

## Repository-readiness gate

A project may become `repository_ready` only after all applicable checks pass:

### Scope and ownership

- canonical name and project identifier are stable;
- repository responsibility is distinct from existing repositories;
- include/exclude rules are documented;
- a maintainer or stewardship path exists;
- release cadence and dependency direction are understood.

### Source structure

- source-of-truth files are identifiable;
- generated files, caches, large artifacts, and local outputs are separable;
- the proposed root tree is coherent and can be installed or cloned directly;
- build, open, or execution instructions are accurate;
- required third-party or physical dependencies are documented.

### Validation baseline

- a reproducible baseline exists;
- applicable compile, ERC, DRC, schema, test, or hardware checks are recorded;
- unresolved limitations are explicit;
- a clean candidate tree can be independently inspected;
- no known unsafe default is being promoted.

### Repository operations

- branch, tag, and release policy are selected;
- authority-marker fields are defined;
- recovery-bundle and release-artifact handling are defined;
- service-account access and Gitweb exposure are preflighted;
- same-disk recovery is not described as backup.

Failure of the readiness gate leaves the project in `incubating`. It does not
remove the project or discard its artifacts.

## Repository-admission transaction

Repository admission follows the same authority discipline used by existing
Project Frankenstein repositories:

1. boundary review;
2. candidate tree and provenance capture;
3. independent candidate verification;
4. staging without changing canonical authority;
5. review of the staging report;
6. compare-and-swap promotion;
7. annotated authority tag where applicable;
8. authority-marker creation;
9. recovery-bundle creation and clone/fsck verification;
10. Gitweb and documentation-surface verification;
11. final independent report validation.

No repository becomes authoritative merely because a bare repository exists or
a branch was pushed.

## Hardware-project additions

Hardware projects also require:

- electrical source-of-truth identification;
- mechanical and footprint hold points;
- power, voltage-domain, reset, and unpowered-state analysis;
- explicit first-article limits;
- fabrication-release and destructive-operation gates separate from repository
  readiness;
- retention of design-package hashes and BOM/pin-map provenance.

Repository readiness does not equal fabrication readiness.

## Retirement and archival

An incubating project may be archived when it is abandoned, superseded, merged,
or determined out of scope. Before archival:

- preserve the last accepted project record;
- retain artifact identities and meaningful evidence;
- record the reason and successor, if any;
- do not delete provenance-distinct source packages merely because no
  repository was created.

## Current implementation

The canonical machine-readable register is:

```text
Migration/Project_Incubation/PROJECT_REGISTER.json
```

The binding contract is:

```text
Operational_Contracts/PROJECT_INCUBATION_AND_REPOSITORY_ADMISSION_CONTRACT.json
```

The first admitted incubating project is the MN103S Optical-Drive IDE Recovery
Programmer. Its repository remains explicitly deferred.
