Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Background to the SCAFFOLD 0.2 addition¶
Status: historical — content accepted on 2026-10-16. PROP-033–PROP-037 are the background to R-033–R-037. Authoritative obligations are in the 0.2 requirements, under the human decision. The text below preserves proposal rationale; it is not a second normative source.
The current edition already covers the project charter and survey (R-019, R-020), planning and human acceptance (R-021–R-024), traceability and branches (R-025, R-026), integration and delivery (R-010, R-027–R-029), crews (R-030, R-031), and operations (R-032). The proposals below focus on relationships that remain weak or implicit. They do not prescribe Jira, Git, Mermaid, a provider, a particular architecture, or a test runner.
Change-impact sequence¶
First identify the changed artifact and its revision. Follow declared relationships to contracts and module boundaries, runtime configuration and topology, migrations, and tests. Evidence that depends on a previous revision becomes pending until rerun or reviewed. Unknown relationships are reported as “not evaluated,” not “no impact.” Required checks and acceptance take place before the identified artifact is promoted.
Candidate proposals¶
SCAFFOLD-PROP-033 — Impact analysis and evidence invalidation¶
Problem. Requirements, stories, contracts, diagrams, configuration, migrations, or components can change while tests and approvals still appear current despite having used an earlier revision.
Proposal. Relevant artifacts declare stable identifiers, revision or digest, authority, relationship type, and applicability. On change, the project identifies affected descendants and marks evidence based on changed inputs as stale. Work is not presented as complete until that evidence is regenerated or reviewed. Dashboards may show this state but do not keep an independent copy of the work source.
Possible check. Change a story in a fictitious example and identify affected criteria, contracts, tests, and components; evidence from the prior revision no longer counts as current. Unknown relationships remain unevaluated.
Existing basis. Strengthens the limited synchronization in R-006 and the artifact-validation guide. It relies on MILPA-R-001, R-007, and R-008 for authority, provenance, and visible contradictions; it does not redefine them.
SCAFFOLD-PROP-034 — Runtime contract and infrastructure-code correspondence¶
Problem. An interface and unit tests may pass while a service reads undeclared environment variables, assumes an unauthorized connection, or exceeds limits unavailable in its real runtime.
Proposal. Where a project is deployed, declare runtime dependencies that affect operation: required and optional configuration, secret references (never secret values), ports and network destinations, relevant resource limits, health checks, runtime dependencies, and required operational properties. Link these declarations to code and deployment manifests. Values are service- and environment-specific; no universal inventory or infrastructure tool is required.
Possible check. Detect consumed but undeclared variables, missing secret references, undescribed network links, and contradictions between application and deployment limits. Evidence identifies revisions and environment; it does not claim that deployment will work everywhere.
Existing basis. Makes R-006, R-010, and R-027–R-028 more concrete. ASILO-R-004 and R-006 continue to govern permissions, data, and secrets; this does not duplicate those security rules.
SCAFFOLD-PROP-035 — Data migration and compatibility¶
Problem. Concurrent software versions, jobs, event consumers, and persistent schemas can become incompatible during gradual deployment or rollback even when each isolated change builds.
Proposal. A persistent-data change declares backward and forward compatibility with versions that may coexist, data effects, migration strategy, verification, recovery, and conditions for retiring old structures. Changes that cannot be atomic and compatible use a dependent work sequence (for example, expand, transition, switch reads, contract); the old version is not removed until observable retirement conditions are met. Irreversible migrations require an explicit recovery strategy and risk acceptance.
Possible check. Migration tests against an ephemeral database with representative data, compatibility tests between concurrent versions, engine-specific DDL review, and rollback or recovery verification. No downtime threshold, batch size, or stability window is universal.
Existing basis. Makes R-010 and R-028 more concrete. The architecture profile already covers data ownership, migration, and recovery; this proposal links them to work and integration evidence.
SCAFFOLD-PROP-036 — Verifiable structural boundaries¶
Problem. API contracts can stay synchronized while internal domain, module, dependency, or data-flow boundaries are violated. Architecture labels alone do not prevent coupling.
Proposal. When a project declares modules, layers, or trust boundaries, identify owners, permitted dependencies, public interfaces, and forbidden relationships. Select checks suited to the language and architecture to detect forbidden dependencies, cross-repository coupling, and drift in relevant diagrams. If a relationship cannot be checked automatically, declare the limitation and review evidence.
Possible check. An architecture test or equivalent analysis fails on a forbidden dependency; a topology change identifies affected contracts, diagrams, and revisions. AST checks, import rules, and static analysis are implementation options, not standard mandates.
Existing basis. Makes R-006 and R-007 more concrete for internal structure. MILPA-R-007 continues to govern cross-project links; no MILPA amendment is proposed.
SCAFFOLD-PROP-037 — Remote connections and actions from local engineering¶
Problem. An assistant on a local computer can use SSH, an API, a database client, or an MCP server with its operator's credentials. Local repository zones do not by themselves restrict remote reads or writes. A local interface also does not imply that model inference is local.
Scope and responsibility. Applies when an AI-assisted engineering task connects to a server, including an inference server, or creates remote effects. The technical owner declares targets and scope; the environment owner authorizes access. Critical-effect decisions retain ASILO-R-005. Human approval is not required for every connection.
Proposal. Link the connection to the work item and declare:
- Execution origin, target, purpose, and environment (development, test, or production). Distinguish the tool's target server from the model inference server. Endpoint, protocol, expected identity, and policy belong in versioned configuration; credentials do not.
- Server identity verification using the protocol's mechanism, such as an SSH host key or TLS certificate. Stop on mismatches for review; the assistant does not disable verification or silently accept a new identity. VPNs, tunnels, and network access do not replace authentication or authorization.
- Session identity, allowed capabilities, remote resources and paths, expiry, revocation, and limits. Access available on the human's computer is not inherited automatically. Authorizing a connection does not grant access to other targets, port forwarding, privilege escalation, or arbitrary command execution.
- Permitted inbound and outbound data: code, files, prompts, logs, results, and retrieved context. Treat remote responses as untrusted. Use credentials outside model context and omit their values from logs. Reading remote data may also expose it to the model provider; evaluate that path.
- Current authorization at the actual execution boundary before each action. Commit review or a local hook cannot control an SSH, SQL, or API action that already happened. Present the specific target and object of a critical effect to the authorized person. Target, action, or scope changes require authorization review; model requests do not expand permissions.
- Outcome and minimal traceability: task, context revision, environment/target, identity, operation, decision, time, and evidence with appropriate classification and retention. If a disconnect leaves an effect uncertain, reconcile state before retrying; do not assume failure or blindly repeat it.
Fictitious example. A batch permits reading sanitized logs over SSH from a test server. The session does not permit production administration or database changes. A proposed migration needs review of its effect, environment, and permissions before execution. Sending the logs to an external model is evaluated separately from reading them over SSH.
Possible check. Test unauthorized targets, changed server identity, revoked or expired sessions, writes with read-only access, and malicious instructions in remote responses. Verify that secrets do not reach the model and uncertain effects are not repeated. Distinguish simulated rejection from controls tested against an authorized remote environment; a manifest alone does not prove containment.
Existing basis. Complements R-001, R-004, R-010, and R-027 for remote engineering. Applies ASILO-R-001, R-003, R-004, R-005, R-006, and R-007 under their conditions. MILPA retains sources, authority, and links; neither accepted edition changes. Horcón or another host may provide adapters and mediation; documenting this proposal does not demonstrate that those controls are implemented.
Scope and responsibility across methods¶
- SCAFFOLD governs the AI-assisted software development lifecycle, from charter and planning through architecture, implementation, integration, delivery, and learning. It does not require multiple agents or an AI-enabled product; one person and one assistant can use it.
- ASILO supplies controls for trust, permissions, data, critical effects, budgets, and AI failure evaluation. Proposals 034, 035, and 037 use those controls when applicable; they do not create parallel security rules in SCAFFOLD.
- MILPA maintains authority, provenance, profiles, sources, and cross-project links. Current requirements cover artifact records and contradictions; no amendment to MILPA 0.1 is identified.
- Horcón may implement readers, analyzers, connectors, views, and gates. A dashboard projects authorized state; it is not an additional authority. External integrations receive only data allowed by the ASILO profile.
- Research, publishing, non-software documentation, and creative work may use Horcón/MILPA/ASILO and their own extensions; that does not make them SCAFFOLD scope.
Review outcome¶
The five proposals were accepted as SCAFFOLD 0.2 additions. Their records formalize conditions, owners, evidence, exceptions, and residual risk. ASILO/MILPA, R-017, and profiles retain their status.