Skip to content

ONB — TFW_20260830-114238_ASSISTED15: Prompt/File Assisted 1.5 Product and Maintenance Bridge

Date: 2026-08-30 Author: saubakirov via Codex Executor Status: ✅ ONB — amendment A1 re-onboarding complete; execution authorized Parent HL: HL-TFW_20260830-114238_ASSISTED15 TS: TS — TFW_20260830-114238_ASSISTED15

1. Understanding

The task replaces the nine-file public Assisted 1.0 starter with one standalone, Russian-authoritative Assisted 1.5 while keeping every product write under editions/. The result must retain the universal field-proven lifecycle, identity, migration and practical-template behavior; exclude Innoforce facts, people, branding and private history; remove the three exact retired lifecycle hooks; and add a deterministic, asymmetric maintenance contract with clean-fixture forward updates, candidate-only reverse promotion and non-mutating comparison of the real mixed field tree. The field source and adjacent versions are read-only evidence. Implementation must stay within the TS's exact 35-path ceiling, finish with reproducible V1–V12 evidence, and make local scoped commits only.

2. Entry Points

  • Frozen contract: [HL-TFW_20260830-114238_ASSISTED15](../../../workspace/2026/TFW_20260830-114238_ASSISTED15/[HL-TFW_20260830-114238_ASSISTED15](../../../workspace/2026/TFW_20260830-114238_ASSISTED15/HL-[TFW_20260830-114238_ASSISTED15](../../../workspace/2026/TFW_20260830-114238_ASSISTED15/HL-TFW_20260830-114238_ASSISTED15.md).md).md).md, freeze commit ee09a8a.
  • Approved execution contract: TS__TFW_20260830-114238_ASSISTED15.md.
  • Research constraints: research/iter1/RES.md D1–D12 and V1–V12; research/iter2/RES.md D13–D23 and V1–V12.
  • Public product: editions/README.md and the current nine paths under editions/02-assisted/.
  • Read-only field evidence: H:\Shared drives\IT\Innoforce AI-First Knowledge\innoforce_starter_v1.5 and its 29-file canonical tree digest 7e2248a7f7e77161644d8394b1557c731e0b5b31d7713843de30655b6e4fadc3, reproduced before onboarding from sorted path<TAB>size<TAB>sha256<LF> records.
  • Field mechanisms inspected: five skill contracts and metadata, tfw_identity.py, root service documents, version/changelog, people/knowledge navigation and practical templates. The four Innoforce knowledge records and logo are exclusion evidence only.
  • Verification entry points to create within the approved paths: editions/maintenance/assisted_maintenance.py and editions/02-assisted/.agents/skills/tfw-identity/scripts/tfw_identity.py.
  • Required process outputs: evidence/EV__TFW_20260830-114238_ASSISTED15.md, the evidence attachment set defined by TS §5, and RF__TFW_20260830-114238_ASSISTED15.md.

3. Questions (blocking — cannot proceed without answers)

# Question Answer
1 Frozen HL §3.1 visualizes the maintenance bridge at editions/ASSISTED_MAINTENANCE.md plus editions/maintenance/, while the approved TS allocates the maintenance script and two records inside the standalone editions/02-assisted/ payload and allocates no outer maintenance paths. May I treat the TS placement as a non-amendment deliverable refinement under HL Contract rule 6 because it preserves standalone use and satisfies HL §5/§6 unchanged? Options: A (recommended) — execute the exact TS topology inside 02-assisted; B — stop for a frozen amendment and a revised affected-file list; C — move only maintainer prose/tooling outside, which would require additional or substituted product paths and risks breaking standalone verification. Coordinator answer: Do not use A. The explicit frozen §3.1 result tree is authoritative; the TS placement was a Coordinator error, not a research amendment. Execute the corrected TS: maintainer prose, records and executable comparison tooling live under editions/ASSISTED_MAINTENANCE.md and editions/maintenance/. The copyable 02-assisted root remains independently usable for project work and carries the complete manual /tfw-update contract; repository-to-downstream maintenance uses the outer tool. No frozen claim changes.
2 Frozen HL §3.1 names шаблоны/assets/<neutral TFW asset>, while the TS exact path list names шаблоны/overlay/mark.svg as the restricted customizable asset. May I treat this as the same non-amendment topology refinement and use the exact TS path? Options: A (recommended) — keep overlay/mark.svg, which matches research TI1 and the six-property overlay boundary; B — replace it with an assets/ path in a revised TS; C — add both, which exceeds the exact path allocation unless another approved path is removed. Coordinator answer: Use the corrected frozen-aligned path шаблоны/assets/tfw-mark.svg. Keep шаблоны/overlay/theme.css as the restricted customizable theme surface. The interface contract belongs in the builder, core CSS and update skill rather than a separate theme-interface.json; this is an implementation refinement within the same frozen template capability and preserves the 35-path budget.
3 AC-4 evidence asks for this task's actual Coordinator/Executor/Reviewer runtime trace, but the Executor must finish EV/RF before the independent Reviewer may start, and neither the Executor nor Reviewer may rewrite EV/RF after the role boundary. Which lifecycle-consistent evidence treatment is authorized? Options: A (recommended) — verify the shipped V11 fixtures and actual Coordinator→Executor targeting in EV, mark only the not-yet-created live Reviewer leg DEFERRED with the lifecycle-order blocker, and require the Reviewer to close that actual-runtime proof in review artifacts; B — require the Phase Coordinator to establish the one Reviewer lineage before execution while leaving it idle until RF, allowing EV to prove target/capability existence but not a completed review; C — amend the evidence plan so actual independent-review completion is explicitly review-stage evidence rather than Executor-stage evidence. Coordinator answer: A. Verify the shipped V11 fixtures and the actual Coordinator→same-Executor lineage now. Mark only the live Reviewer leg DEFERRED — reviewer cannot start before terminal RF/evidence. The one Reviewer session will be created after RF and must close this proof in REVIEW traces; it does not rewrite EV/RF. This is lifecycle ordering, not an amendment or evidence waiver.

4. Recommendations (suggestions, not blocking)

  1. Treat release-manifest.json, maintenance-policy.json and the maintenance implementation as one public standalone interface: closed schemas may remain embedded in the approved script path, as TS §6 expressly permits, avoiding an unauthorized product path.
  2. Keep VERSION as exact 1.5\n while recording the 1.5 changelog entry as Unreleased until a later release workflow establishes a real public release date; do not infer a date or tag from the private field lineage.
  3. Use the maintenance script's own deterministic fixture runner as the single shipped verification entry point for V1–V6 and V9–V12, and keep identity V7–V8 in the identity script's isolated self-test. This keeps all executable behavior inside the two approved script paths.
  4. Recompute every count, digest, product-path census and source digest immediately before RF rather than copying onboarding figures into final evidence.

5. Risks Found (edge cases, potential issues not in TS)

  1. The 4,800 changed-product-line ceiling is materially tighter than the source lineage: neutral service prose, five skills, two safety implementations and complete fixtures can exceed it even while the 35-path ceiling passes. I will measure after each incremental slice and stop before an overrun.
  2. The field source is on a synchronized H: drive. Its onboarding digest matches the research pin now, but a later visible change would invalidate extraction evidence; the source digest must be checked before every field comparison and again after execution.
  3. Actual offline A4 and presentation rendering depends on locally available renderer/font capabilities. Missing rendering support is an evidence blocker, not permission to mark V9 verified or to add undeclared product dependencies.
  4. A conventional %LOCALAPPDATA% path alone does not prove operational-local-v1. The Windows adapter must check the complete ancestor/reparse/provider/ACL boundary and select zero-write session-only when any predicate remains unknown.
  5. Deterministic marker/hash scans cannot establish semantic neutrality. The Executor can supply a complete synthetic leak corpus and public-projection noninterference proof, but the independent Reviewer must still perform the required semantic privacy judgment.
  6. The current source updater treats шаблоны/ as wholesale service content and its identity implementation performs only final-path symlink checking. Those bytes are evidence of field evolution, not safe code to transplant unchanged.

6. Inconsistencies with Code (spec vs reality)

  1. The current public edition still contains exactly the three stock hook paths that the field lineage removed in 1.4; their SHA-256 values match the recorded retirement baseline, so deletion is authorized only for these exact current bytes.
  2. The current public package has 9 files, no VERSION, no public changelog, no skills and no practical templates; every one of its six paths shared with field 1.5 differs, so there is no byte-copy baseline.
  3. The pinned field 1.5 source has 29 files and reproduces the research digest, but 14 text files plus knowledge records and the logo contain organization/environment residue. Its own neutral-package wording is therefore not sufficient public-release evidence.
  4. The source tfw_identity.py checks only whether the final store path is a symbolic link and uses path resolution; it does not implement the TS-required complete Windows ancestor/reparse and operation-time locality proof. The public identity implementation must be strengthened rather than copied.
  5. The source updater has no reverse-promotion implementation and classifies templates for broad replacement. The approved public bridge must therefore implement P6 for the real mixed lineage and demonstrate P2 only on clean overlay-separated fixtures.

7. Knowledge Citations

# HL §7.2 ref Read? Applied / N/A Notes
1 K1 — README.md § How It Works, “Proportional discipline across domains” ✅ Applied Assisted stays independently usable and bounded below Full while preserving the common continuity contract.
2 K2 — .tfw/README.md NS1 and NS3 ✅ Applied The design preserves human-governed continuity and rejects private coupling, vendor-specific assumptions and unsupported automation.
3 K3 — .tfw/README.md Methodology values and Success Criteria ✅ Applied File-backed role gates, evidence, portability and resumable traces are verified rather than claimed in prose.
4 K4 — knowledge/philosophy.md F32–F34 ✅ Applied Extraction preserves goals/sources/decisions/verification, while worked templates and follow-through make the edition useful beyond trace creation.
5 K5 — KNOWLEDGE.md D57–D60 ✅ Applied The visible edition topology and honest manual baseline remain; obsolete hooks are removed and non-Git root behavior is handled explicitly.
6 K6 — .tfw/conventions.md §§3, 11, 14 ✅ Applied No placeholders, no scope changes, no evidence inflation and no Executor edits to frozen/planning/review artifacts.
7 K7 — knowledge/convention.md F20 ✅ Applied PROJECT.md, people and knowledge navigation ship visibly uninitialized rather than with plausible organization defaults.
8 K8 — knowledge/constraint.md F10 ✅ Applied The copied Assisted root includes every runtime dependency it needs and does not require Light, Full or the field source.
9 K9 — knowledge/process.md F27–F29 ✅ Applied Lifecycle/identity checks address routine trace failures; initialization establishes the real project; evidence and human acceptance remain distinct.
10 K10 — knowledge/stakeholder.md F4–F5 and F8 ✅ Applied Onboarding remains low-friction and non-redundant; deterministic checks are expected to become silent when the package is clean.

No additional PV item changes the approved implementation boundary. knowledge/process.md F32 is additionally relevant to evidence technique: every final count and quotation must be recaptured immediately before RF with raw output retained.

ONB — TFW_20260830-114238_ASSISTED15: Neutral Assisted 1.5 Product and Maintenance Bridge | 2026-08-30

8. Amendment A1 Re-onboarding

8.1 Supersession notice

This section is the current Executor onboarding authority. Where §§1–7 describe executable identity, locality, registry, locking, maintenance, update or product self-test behavior, amendment A1 supersedes those statements. The retained earlier text is historical trace and is not an implementation instruction.

  • Re-frozen HL authority: 37b61d4.
  • Revised approved TS authority: f4c676c.
  • Formal review trigger: revision 3 commit 58d6ccc; its D11 runtime repair is canceled by A1 rather than continued.
  • Final product contract: TFW mechanics are prompts, Markdown skills, static records and ordinary agent file operations. шаблоны/build_a4.py is the only permitted product Python file and remains an artifact builder only.

8.2 Current understanding

The same standalone neutral Russian Assisted 1.5, lifecycle roles, templates, version/changelog, exact hook removal, downstream preservation and both maintenance directions remain required. The implementation now removes both task-added TFW runtime files and every dependent command or claim. Identity becomes a closed Markdown procedure that reads people/*.md, applies the exact one-valid-profile rule, asks one concise human question on every other unresolved case, and creates only an explicitly approved profile file after collision recheck. Maintenance becomes an agent-led compare → classify → plan → explicit gate → recheck → ordinary file changes → verify → candidate/review procedure over declarative manifest and policy records. No registry, ACL, lock, journaling engine, transaction claim or shipped product self-test remains.

8.3 Questions (blocking)

No blocking question. The amended HL, revised TS and Coordinator mandate agree on the two deletions, the absence of any replacement executable, the final 33-path/2,600-line ceiling, the external-tag treatment and the Coordinator-only post-RF history compaction.

8.4 Risks and controls

  1. Stale runtime references may survive outside the two deleted files. Control: scan every product text, metadata, JSON and builder semantic surface for removed filenames, commands, registry/ACL/lock/runtime/self-test claims and correct each approved existing path.
  2. Runtime removal reduces the budget but extensive prose may still exceed 2,600 changed product lines. Control: recompute final f3eb986 census after each coherent slice and stop before any 34th path, 24th addition or line overrun.
  3. A prompt procedure can become vague or guess identity. Control: retain a closed zero/one/multiple/invalid/fixed/autonomous/surname/collision table and prove negative cases change no fixture bytes.
  4. Agent-led update prose can conceal unclassified or drifted state. Control: require complete inventory, one authority per path, a single exact gate, immediate recheck, ordinary file operations, post-manifest and honest partial return.
  5. Old evidence reports runtime success and an obsolete empty tag-containment set. Control: supersede those conclusions explicitly, regenerate AC-1–AC-10 evidence, retain the external tag unchanged and distinguish external containment from zero Assisted tag/push acts and zero remote containment.
  6. History compaction is required only after terminal amended RF/evidence. Control: the Executor performs no rewrite, rebase, backup branch or ref mutation and returns a clean task boundary to the Coordinator.

8.5 Current inconsistencies to resolve inside approved paths

  1. editions/02-assisted/.agents/skills/tfw-identity/scripts/tfw_identity.py and editions/maintenance/assisted_maintenance.py still implement the superseded runtime and must be absent from the final baseline diff.
  2. Identity/update skills, Assisted docs, migration guidance and maintainer documentation still describe script commands, machine registry, ACL/locality or automatic verification semantics.
  3. release-manifest.json still lists both runtime files; maintenance-policy.json still names executable verification/update behavior rather than declarative authority.
  4. RF, EV, fixture results, verification log and boundary attestation still count the superseded runtime runs as current proof and contain stale global no-tag-containment language.

8.6 Knowledge citations under A1

All ten HL §7.2 citations were reread through the re-frozen contract. Their current application is prompt/file structural enforcement, standalone operation without hidden machine state, visible uninitialized files, useful templates, proportional evidence and honest manual capability. A1 is the authoritative constraint when earlier research or this ONB's historical §§1–7 suggests custom runtime enforcement. No additional PV item authorizes code, a scope overrun or Executor-led history rewriting.

Amendment A1 re-onboarding — TFW_20260830-114238_ASSISTED15 | 2026-08-30