HL — TFW_20260830-114238_ASSISTED15: Promote Field-Proven Assisted 1.5 into TFW Editions¶

Date: 2026-08-30 Author: saubakirov via Codex Coordinator Abbreviation: ASSISTED15 Status: 🟡 TS_DRAFT — owner-approved no-code amendment applied; revised TS prepared Contract: 🔒 FROZEN — approved by saubakirov 2026-08-30 Frozen: §1 · §3 · §4 · §5 · §6 · §7 — locked on owner approval Free: §2 · §7.2 · §8 · §9 · §10 · §11 — research updates these directly Append-only: §12 Amendment Log — the only channel for changing a frozen section Baseline: freeze commits — recovery form in conventions.md §3 rule 15

Project North Star: README.md opening and § How It Works · [.tfw/README.md](../../../concepts/philosophy.md) NS1–NS3

1. Vision 🔒 FROZEN¶

TFW Editions ships a complete Assisted 1.5 whose behavior comes from the real Innoforce field lineage but whose public payload contains no Innoforce facts, people, project identity, or private organizational memory. A user can copy one standalone starter, initialize it naturally, work through result-first planning, execution, independent review, human acceptance, and reusable templates, while maintainers can move universal improvements between the public core and an Innoforce overlay without blind mirroring.

Impact: Assisted becomes a maintained product rather than a frozen 1.0 experiment: the proven lifecycle, identity model, update discipline, practical templates, release history, and downstream feedback loop become available to any suitable project without importing one company's context.

“The Innoforce folder is real practice: keep its useful logic and templates, remove our private knowledge, and let everyone reach the same way of working.”

2. Current State (As-Is) 🟢 FREE¶

Repository edition versus field source¶

Measure	`editions/02-assisted`	Innoforce `innoforce_starter_v1.5`	Consequence
Files	9	29	This is a product reconstruction, not a small patch
Shared relative paths	6	6	Every shared file differs
Source-only files	0	23	Versioning, skills, identity and templates are absent here
Local-only files	3 hooks	0	The public edition still ships the mechanism field release 1.4 removed
Exact file matches	0	0	No subtree can be declared synchronized today
1.4 → 1.5 field delta	—	3 added + 15 changed	Identity is the defining 1.5 change

The source requested by the owner resolves to:

H:\Shared drives\IT\Innoforce AI-First Knowledge\innoforce_starter_v1.5

The originally stated intermediate innoforce\_starter\_v1.5 path does not exist. The same parent contains preserved 1.2, 1.3, 1.4 and current starter directories, and the 1.5 changelog records the lineage from 1.0 through 1.5.

What the field lineage proved¶

Version 1.2 introduced edition versioning, a changelog, /tfw-plan and /tfw-update.
Version 1.3 moved tasks to stable paths and added execution plus independent review.
Version 1.4 added manual/autonomous orchestration and removed unreliable lifecycle hooks from the clean payload.
Version 1.5 added a multi-user identity contract, separate Full/Assisted local stores, surname-based identifiers for new profiles, shared-write checks, and a neutral-package claim.
The field package also accumulated output templates and organizational knowledge because useful results, not process files alone, were needed in practice.

Why the field package cannot be copied literally¶

The 1.5 package calls itself neutral, but its material payload is mixed:

Class	Examples	Public disposition
Universal Assisted behavior	lifecycle skills, identity semantics, stable traces, gates, safe update rules	Promote as Markdown and ordinary file procedures; do not promote the source runtime
Practical product templates	work plan, note, A4 document, presentation, builder, asset	Keep the capability; remove company examples and branding
Innoforce private or organizational context	company facts, leaders, products, goals, constraints, people context	Exclude
Environment-specific wording	Innoforce role, mandatory Google Drive assumptions, organization-specific source paths	Generalize to capability-based wording
Experimental legacy	`.codex` lifecycle hooks	Remove; manual order and skill gates remain authoritative

Fourteen text files in the pinned field 1.5 snapshot contain direct Innoforce, Google Drive, Shymkent or related organizational markers; corporate knowledge records and the logo add further non-neutral material. A literal copy would therefore contradict the public starter's portability and initial-project-unknown contract. The three public hook files exactly match known field stock hashes retired in 1.4, so stock removal can be proved without treating modified or unrelated .codex/ content as disposable.

Owner architecture ruling after implementation review¶

On 2026-08-30 the owner explicitly ruled that TFW registration, identity and update mechanics must remain prompt/file-only and must not ship executable workflow code. The field source is evidence for the desired human behavior, not authority to copy its Python helper. The three independent review cycles and the actual Windows icacls hang showed that the added ACL/locality runtime was disproportionate to the simple participant-registration operation. The approved amendment is recorded in §12 and supersedes the executable identity and maintenance interpretation introduced by research.

Scope boundary¶

Product changes are limited to editions/.
.tfw/, root public guides, editions/01-light/, task history, and unrelated dirty worktree changes are not product targets.
The owner's separate scope-budget change is recorded in commit f3eb986; it is a planning input and does not authorize any further Full TFW or .tfw/ product changes during implementation.
This task's own workspace/... traces are process records required by TFW, not product modifications.
The field-proven Russian user layer remains the 1.5 baseline for this task; public English localization is a separate product decision rather than a silent translation mixed into synchronization work.

3. Target State (To-Be) 🔒 FROZEN¶

Product boundary¶

Concern	Public Assisted 1.5	Innoforce overlay	Promotion rule
Lifecycle and gates	Canonical	Consumes the public core	Public core → overlay through versioned update
Identity mechanism	Markdown skill: inspect profiles, ask the human, write ordinary project files	Uses the same prompts with company profiles	Generic procedure improvements may return through reviewed promotion; executable registration does not
Starter project state	Uninitialized and neutral	Corporate defaults may be prefilled	Downstream state never enters the public package
Knowledge	Empty navigation and schema	Company records remain downstream	No reverse promotion of organizational facts
Templates	Useful neutral set	May carry brand-specific variants	Semantics can promote; branding stays downstream
Version history	Assisted product changelog	Downstream may add its own overlay history	Histories remain distinguishable
Synchronization	Static manifest/policy plus skill-driven compare, update and promotion instructions	Explicit overlay owner	No executable update engine and no automatic two-way mirror

The public product is functionally complete at Assisted version 1.5, but byte identity with the Innoforce distribution is not a goal. Completeness means every universal 1.5 behavior is expressible through prompts, Markdown skills and ordinary file operations, and every useful template category is present and verified. Neutrality means company-specific state is absent. TFW mechanics ship no executable registration, identity, maintenance, update or self-test runtime; build_a4.py remains solely an artifact-template builder.

3.1 Result Visualization¶

FINISHED PUBLIC REPOSITORY

editions/
├── README.md                                      accurate edition choice
├── ASSISTED_MAINTENANCE.md                       core/overlay ownership and release route
├── maintenance/                                  static release manifest + policy
└── 02-assisted/                                  standalone copyable root
    ├── AGENTS.md                                 neutral result-first contract
    ├── README.md                                 natural onboarding and honest limits
    ├── PROJECT.md                                uninitialized; no company/project identity
    ├── MIGRATION.md                              Light and installed-Assisted preservation
    ├── VERSION                                   1.5
    ├── CHANGELOG.md                              truthful Assisted history
    ├── .agents/skills/
    │   ├── tfw-plan/                             plan + Gate 0 + orchestration
    │   ├── tfw-handoff/                          bounded execution
    │   ├── tfw-review/                           independent verdict
    │   ├── tfw-update/                           agent-led compare/update/promotion procedure
    │   └── tfw-identity/                         prompt/file participant procedure; Markdown only
    ├── people/README.md                          dynamic profiles, no shipped humans
    ├── knowledge/INDEX.md                        empty navigation, no Innoforce records
    └── шаблоны/                                  neutral practical outputs
        ├── план_работы.md
        ├── заметка.md
        ├── документ_A4.md
        ├── презентация.html
        ├── build_a4.py
        └── assets/<neutral TFW asset>

COPY CONTENTS INTO A PROJECT
        ↓
natural initialization → participant gate → result-first plan → handoff
        → independent review → human acceptance → durable trace and useful result

MAINTENANCE LOOP

public core ──skill-driven reviewed file update──▶ Innoforce core layer + private overlay
     ▲                                               │
     └── agent-prepared generic candidate ◀──────────┘
         private facts and branding cannot cross this boundary

The stakeholder sees one usable starter, not a framework-internal reconstruction exercise. The Innoforce value is visible in the workflow and the practical results it helps create, while Innoforce private content is visibly absent.

3.2 Value Flow¶

Step	Input	Transformation	Value Created
Field extraction	Versions 1.0–1.5 and current public 1.0	Separate proven product behavior from company overlay	Practice becomes reusable evidence, not folklore
Neutralization	Mixed field package	Remove company state; generalize environment assumptions; preserve behavioral invariants	Any project can initialize honestly
Product completion	Lifecycle, prompt/file identity, templates, migration history	Assemble one standalone versioned Assisted root with no executable TFW mechanics	Users get a useful result-producing starter without a hidden local service
Release verification	Static package inventory plus task-local evidence	Check manifests, hooks absence, state preservation, links, skills and prompt/file identity cases	“1.5” becomes an evidenced release claim without shipping a product test engine
Forward update	Public 1.5 + downstream overlay	Agent compares static manifests/policy, presents the classified plan and applies ordinary file edits after the gate	Innoforce receives public improvements without losing its context
Reverse promotion	Downstream generic delta	Agent compares, classifies, removes organization state and prepares an independently reviewed candidate	Field learning improves the public edition without leaking private knowledge

4. Phases 🔒 FROZEN¶

This is one internally coherent product update executed as a single technical phase. After the owner-approved no-code supersession, the exact implementation budget is at most 33 product paths: 23 new, seven modified and three deleted, with at most 2,600 changed product lines. Task traces remain inside the configured ceilings of 50 files, 50 new files, 5,000 changed lines and 50 modified files. The phase boundary is the complete public Assisted 1.5 release: prompt/file lifecycle and identity, templates, static maintenance bridge and release verification are reviewed together because they share one version and one product contract.

Single Phase: Neutral Assisted 1.5 Product and Maintenance Bridge 🔴¶

Requires: the current public edition, Innoforce versions 1.2–1.5, the accepted owner boundary in this task, D57–D60, TFW-52 closure evidence, and owner-updated scope budgets recorded in commit f3eb986.

Context for coordinator: read the predecessor set from §2, this HL, the source CHANGELOG.md, all five source skills and the source identity helper as historical evidence, current public Assisted files, the practical template set, the final research synthesis and amendment A1. Do not treat the source helper or research locality runtime as product authority.

Key decisions: field practice is evidence, not authority over public product architecture; company knowledge is excluded; templates are product behavior; lifecycle hooks remain removed; TFW registration, identity, maintenance, update and product self-test mechanics are prompt/file-only; build_a4.py is permitted only as an artifact-template builder.

Deliverables:

A standalone, uninitialized and organizationally neutral Assisted 1.5 root.
Truthful version and changelog ownership for the Assisted product lineage.
The complete plan → handoff → independent review → human acceptance lifecycle, including manual and explicitly authorized autonomous modes.
Prompt/file multi-user identity with separate corporate/project roles and stable task ownership: the Markdown skill inspects project profiles, asks the human when needed and uses ordinary agent file operations; no executable registration, local registry or OS security subsystem ships.
Safe Light/Assisted upgrade behavior that preserves project identity, work, knowledge, profiles and customized material unless an exact migration rule and gate authorize a change.
Removal of experimental TFW lifecycle hooks and all claims that they are operational.
Neutral practical templates covering the field-proven categories: note, A4 document, work plan, presentation and deterministic A4 builder, with a non-Innoforce asset.
An editions/-local maintenance contract that classifies core-owned, customizable and downstream-only paths.
Static manifest/policy authority and an agent-led /tfw-update procedure for public-core → overlay and overlay → promotion planning, with explicit stop conditions for unclassified or changed baselines and no executable maintenance engine.
A complete task-local evidence matrix for package neutrality, lifecycle behavior, prompt/file identity cases, migration preservation, template output, hook absence and both maintenance directions; no product self-test runtime ships.
Accurate editions/README.md guidance that describes Assisted 1.5 without promising quiet lifecycle hooks.

5. Definition of Done (DoD) 🔒 FROZEN¶

✅ 1. Assisted implementation diffs after the owner-config baseline f3eb986 are confined to editions/; .tfw/, root guides and editions/01-light/ receive no further changes and remain byte-identical to that baseline.
✅ 2. editions/02-assisted/VERSION is exactly 1.5, and its changelog truthfully distinguishes universal Assisted history from Innoforce-only downstream history.
✅ 3. The copyable 1.5 root is independently usable and starts uninitialized: it contains no Innoforce facts, people, project_id, work, task evidence, local binding, company role, corporate source path or corporate logo.
✅ 4. Every universal 1.5 behavior is present as a prompt, Markdown skill, static contract or ordinary file procedure: natural onboarding, stable task paths, manual/autonomous execution choice, separate plan/handoff/review roles, human acceptance, knowledge decision and safe update planning.
✅ 5. Five skills and their metadata are complete; tfw-identity is a Markdown-only procedure that reads profiles, asks the human and directs ordinary project-file changes without a Python helper, local registry, hidden service or OS security subsystem.
✅ 6. Participant, corporate role, project role, task owner and AI role remain distinct; prompt/file profile creation never overwrites an existing target, and existing valid identifiers are not mass-renamed.
✅ 7. The public payload contains no active TFW lifecycle hooks, executable registration, identity, maintenance, update or product self-test runtime. build_a4.py is permitted only as an artifact-template builder, and documentation states this boundary explicitly.
✅ 8. The skill-driven installed-project update procedure preserves work/, project knowledge, people, project identity, personalization, unrelated .codex/ content and customized templates unless an exact version-specific migration with preconditions is shown and approved at one gate.
✅ 9. The practical template set covers the field-proven result categories and is neutralized without reducing it to empty placeholders or Innoforce-branded examples.
✅ 10. The A4 builder and presentation/document templates render or execute in their intended local environment, with evidence artifacts proving readable output and neutral branding.
✅ 11. Static manifest/policy files assign one authority to each file class—public core, customizable overlay or downstream-only state—and the Markdown update skill defines the compare, gate, apply, verify and promotion procedure; no path is implicitly bidirectional.
✅ 12. Agent-led public-core → Innoforce and Innoforce-generic → public candidate procedures are each demonstrated from clean fixtures with manifests before/after, zero unexplained changes and no private-data transfer; neither demonstration depends on shipped maintenance code.
✅ 13. Task-local evidence covers uninitialized state, zero/one/multiple profiles, new/existing profiles, Cyrillic/Latin surnames, missing surname, surname collision, explicit ask/fixed/missing/invalid selections, manual/autonomous roles, stable/legacy IDs and the absence of any Full/Assisted local registry coupling.
✅ 14. editions/README.md, Assisted README.md, MIGRATION.md, skills, templates, version and changelog agree on paths, version, lifecycle, identity, template ownership and honest capability limits.
✅ 15. The final product diff stays within the amendment budget of 33 product paths—23 new, seven modified and three deleted—and at most 2,600 changed product lines, inside the owner-updated configured ceilings; otherwise execution stops for a new owner ruling.

6. Definition of Failure (DoF) 🔒 FROZEN¶

❌ 1. Any implementation file outside editions/ changes after baseline f3eb986, including .tfw/, a root guide or Light.
❌ 2. Innoforce facts, people, products, leadership, company values, project defaults, corporate paths, branded assets or other organizational state enter the public package.
❌ 3. “Fully 1.5” is implemented as byte-copying the mixed field package, or conversely as omitting universal lifecycle, prompt/file identity, skill-driven update or practical-template behavior.
❌ 4. Experimental lifecycle hooks or any executable TFW registration, identity, maintenance, update or product self-test runtime remain installed, or the product claims automatic startup, checkpoint or finish enforcement.
❌ 5. Forward synchronization overwrites an Innoforce overlay, user knowledge, profile, task trace, project identity, unrelated hook or customized template without an exact classified gate.
❌ 6. Reverse synchronization is a blind mirror, imports private knowledge, or promotes a field delta without separating generic behavior from company context.
❌ 7. The Markdown update procedure silently edits an unclassified path, ignores a changed baseline or manifest discrepancy, or skips the explicit human/reviewer gate.
❌ 8. Package-local, shared, source-controlled or machine registry state silently selects the current participant, or TFW ships a Full/Assisted device-binding subsystem instead of asking through the prompt/file procedure.
❌ 9. The public and downstream changelogs or version authorities become indistinguishable, so neither direction can explain what changed and who owns it.
❌ 10. Templates are kept only as prose promises, remain Innoforce-branded, or fail to produce readable intended outputs.
❌ 11. Existing Assisted project state or legacy identifiers are rewritten to make the new package look clean.
❌ 12. The final product exceeds 33 affected paths, 23 new files or 2,600 changed product lines without an explicit owner-approved amendment.
❌ 13. build_a4.py performs registration, identity, lifecycle, update, maintenance or product verification work instead of remaining an artifact-template builder.

On failure: stop the affected phase before broadening the write set, preserve the exact manifests and evidence, restore the last verified edition package if necessary, and return to /tfw-plan for an owner ruling. Do not repair a boundary failure by adding an automatic mirror, a second active contract, or edits to Full TFW.

7. Principles 🔒 FROZEN¶

Field practice is evidence, not product authority — promote the human behavior that survived real use; never copy field runtime or organizational context merely because it exists downstream.
Templates are product behavior — users reach result-first discipline through usable output forms, not process documents alone.
Neutral core, explicit overlay — public Assisted owns universal behavior; Innoforce owns its facts, people, defaults and branding.
One static authority per file class — every maintained path has one declared owner and one documented file rule.
Promotion, not blind synchronization — reverse flow is an audited product decision; forward flow is an agent-led reviewed file operation that preserves downstream state.
Standalone by default — a copied edition must work without Light, Full, Innoforce files, a local registry, a hidden service or other machine runtime.
Human authority and honest automation — autonomous orchestration requires explicit bounded permission; lifecycle hooks are not claimed operational.
Stable trace over moving state — status changes inside one task trace; paths and accepted history are not rewritten for convenience.
Prompt and files over workflow runtime — TFW mechanics are Markdown contracts executed by the agent with ordinary tools; no custom registration, identity, maintenance, update, locking or ACL subsystem ships.
Functional completeness over byte identity or executable complexity — the public release is complete when universal behavior and useful template categories are present, neutral and evidenced; custom code is not a proxy for completeness.

7.1 Quality Contract 🔒 FROZEN¶

Product paths in scope begin with editions/; process traces in this task do not authorize other product edits.
The Innoforce source path is evidence in this task, not a hard-coded public dependency.
No shipped starter contains a human profile, current-user marker, generated project UUID, work folder, task result, evidence or local registry.
No shipped TFW mechanic requires Python, PowerShell, shell, JavaScript or an OS-level ACL/locking helper. The sole permitted Python product file, шаблоны/build_a4.py, builds user artifacts and is outside registration/workflow mechanics.
No public text asserts that a missing lifecycle hook is a failure; the manual path is the supported baseline.
The changelog records capability boundaries and migration requirements, not marketing-only release claims.
Generic template semantics may be shared; company logos, examples, facts and house style remain an overlay unless explicitly released as neutral TFW assets.
Every skill-driven update starts with a read-only file comparison, exact static preconditions, one complete gate and a post-change manifest; no executable updater or product self-test engine exists.
Existing unrelated dirty changes in the repository remain untouched.
User-facing Assisted 1.5 content keeps the field-proven Russian baseline in this task; localization is not silently combined with core extraction and synchronization.

7.2 Knowledge Citations 🟢 FREE¶

#	Source	Item	How it applies
K1	`README.md` § How It Works	“Proportional discipline across domains”	Requires Assisted to preserve the shared continuity contract while remaining smaller than Full and usable outside software work.
K2	[`.tfw/README.md`](../../../concepts/philosophy.md) NS1 and NS3	Purposeful human-governed continuity; non-goals include vendor binding and documentation bureaucracy	Rejects company-specific/public coupling, false automation and process growth that does not improve continuation.
K3	[`.tfw/README.md`](../../../concepts/philosophy.md) Methodology values and Success Criteria	Structural Enforcement, Portability, resumable checkpoints, acceptance-ready results	Supports file-backed lifecycle gates, local-state exclusion, templates and evidence rather than prose promises.
K4	[`knowledge/philosophy.md`](../../../knowledge/philosophy.md) F32–F34	Preserve goals/sources/decisions/verification; teaching produces a live result; vague requests must reach a usable result	Makes field-proven templates and follow-through part of Assisted rather than optional corporate decoration.
K5	`KNOWLEDGE.md` D57–D60	Editions topology; Assisted's honest manual mode; capability boundaries; root resolution outside Git	Preserves standalone edition topology and honesty while superseding the obsolete hook payload with later field evidence.
K6	[`.tfw/conventions.md`](../../../reference/conventions.md) §3, §11 and §14	North Star alignment, no placeholders, structural gates, evidence honesty, no scope drift	Sets the planning/review standard and prohibits broadening into the Full core.
K7	[`knowledge/convention.md`](../../../knowledge/convention.md) F20	Starter initial files are product behavior and must visibly represent “project unknown”	Requires an uninitialized public package and forbids plausible Innoforce defaults in `PROJECT.md`.
K8	[`knowledge/constraint.md`](../../../knowledge/constraint.md) F10	Every edition must be independently usable	Prevents Assisted from depending on Light, Full or an Innoforce overlay at runtime.
K9	[`knowledge/process.md`](../../../knowledge/process.md) F27–F29	Routine trace/status/index failures recur; initialization must establish the real project; acceptance and evidence differ	Supports skills and identity gates while keeping field evidence and human acceptance distinct.
K10	[`knowledge/stakeholder.md`](../../../knowledge/stakeholder.md) F4–F5, F8	Low-friction entry, non-redundant onboarding, and silent checks rather than permanently noisy drift	Requires natural onboarding and a maintenance check that becomes clean after known divergence is resolved.

Primary-source implementation constraints are consolidated in research/iter2/RES.md. Amendment A1 supersedes its custom locality/locking runtime as product architecture; the research remains evidence for why a prompt/file procedure must state limits honestly. RFC 8785 and JSON Schema inform the static manifest/policy format; W3C CSS/SVG specifications define the closed offline template interface; NIST/OWASP define privacy-report limits; official OpenAI documentation bounds runtime role automation; Git and SemVer sources prevent false release provenance.

8. Dependencies 🟢 FREE¶

Dependency	Status
Current `editions/02-assisted/` baseline and its three hook files	✅ inspected and inventoried
Innoforce `innoforce_starter_v1.2`–`v1.5` directories	✅ available on mounted `H:` drive
Full source `innoforce_starter_v1.5` with `VERSION=1.5` and changelog	✅ read; 29-file manifest captured
Source lifecycle skills, identity contract and identity implementation	✅ read as field evidence; source Python is not public product authority after A1
Field 1.5 mixed-evidence tree digest	✅ pinned as `7e2248a7f7e77161644d8394b1557c731e0b5b31d7713843de30655b6e4fadc3`
Field reverse-promotion implementation	⚠️ absent; current mixed paths require agent-led reviewed reconstruction, never automatic mirroring
Official primary constraints for paths, checksums, local state, sync, release consistency, localization and runtime autonomy	✅ gathered and challenged in `research/iter1/RES.md`
`operational-local-v1` platform adapters and pinned-root safe primitives	➖ superseded as product runtime by owner amendment A1; no custom locality/ACL/lock subsystem ships
Static manifest/policy and portable path rules	✅ retained as agent-readable release authority; product runtime validation is superseded by A1
Blocked-network A4/presentation renderer and visual inspection	⚠️ required implementation evidence; readability, not pixel identity, is the target
Reusable-role runtime adapter	✅ abstract contract defined; capability/target is re-probed before every dispatch and manual-complete remains normative
Owner approval of abbreviation `ASSISTED15`	✅ 2026-08-30
Owner boundary: exclude company knowledge, keep practical templates, promote field logic	✅ 2026-08-30
TFW-52 Assisted history and closure context	✅ read; formal evidence limits remain visible
Owner-updated scope budgets (`50 / 50 / 5000 / 50`)	✅ synchronized and committed as `f3eb986`

9. Risks 🟢 FREE¶

Risk	Probability	Impact	Mitigation
The “neutral” source silently carries corporate material	High	High	Explicit neutralization ledger, private-marker scan, clean-package manifest and DoF 2
Generic and branded templates share paths and are overwritten during updates	High	High	File-class ownership, stock hashes, customizable-template protection and overlay fixtures
Bidirectional wording is interpreted as automatic mirroring	High	High	Use “agent-led forward update” and “reviewed promotion”; ship no maintenance engine
Removing hooks leaves stale capability claims	High	High	Cross-file claim scan and hook-absence scenarios in the single release matrix
Prompt identity silently guesses a participant or conflates participant, roles and owner	Medium	High	Markdown skill enumerates profiles, asks one explicit question on ambiguity, and writes only the user-approved profile/task fields
Autonomous task operations differ across Codex builds	Medium	High	Capability detection, manual fallback and no promise when thread operations are absent
Source or Drive-visible files change during execution	Medium	High	Capture pre-manifest, re-read baseline before use, stop on drift; never write the field source during extraction
A broad single-phase diff hides a boundary error between core, templates and overlay	Medium	High	Static classified manifest, bounded write set, task-local checks and one integrated RF/review against the release contract
A normalized changelog rewrites corporate history into a false public release history	Medium	High	Preserve provenance and explicitly label downstream-only milestones instead of claiming byte-identical releases
Existing unrelated worktree changes are overwritten	Low	High	Limit write paths and verify the exact diff before every phase handoff
A future contributor reintroduces executable registration/update mechanics for “safety”	Medium	High	Explicit DoD/DoF/Principle A1 boundary, product code inventory and independent semantic review
Case, Unicode normalization or reserved-name differences make a static path comparison ambiguous	Medium	High	The update skill stops and asks for review; it never normalizes or edits an ambiguous path automatically
Static hashes describe a stale or mixed release	Medium	High	Re-read every source/target path immediately before the gated ordinary file update and recapture the post-change manifest
A reverse report leaks sensitive downstream paths or hashes despite omitting contents	Medium	High	Default-deny authority classes; keep sensitive details in private evidence and publish only reviewed generic candidates
Agent-led forward edits are applied directly to today's mixed field files without classification	Medium	High	Candidate-only reconstruction is mandatory until downstream overlays are structurally separated and reviewed
Valid hashes are mistaken for source authentication	Medium	High	State that JCS/SHA-256 proves coherence and integrity only; reviewed repository/source selection supplies provenance
An agent-led multi-file update is described as transactional	Medium	High	Document it as a reviewed sequence of ordinary file operations; recapture partial state honestly and stop on drift
Renderer and system-font variance changes pagination or glyph layout	Medium	Medium	Verify readable blocked-network output on supported renderers; make no pixel-identity promise
Deterministic privacy scans miss semantic disclosure	Low	High	Require independent semantic privacy/usefulness review before public projection or reverse promotion
Runtime role capabilities disappear or a handle becomes ambiguous	Medium	Medium	Re-probe per dispatch; preserve existing trace lineage and stop/manual-complete without automatic duplication

10. RESEARCH Case 🟢 FREE¶

Whether all field mechanisms remain coherent after removal of Innoforce-specific wording and branded state.
The smallest static manifest/policy that supports agent-led work in both directions without becoming a second product runtime.
Whether practical templates should be protected as project customization, stock-updated by hash, or split into core and overlay subtrees.
The evidence needed to claim autonomous orchestration across currently available Codex task operations.
Whether the Russian 1.5 baseline should remain the public Assisted language or be followed by a separate English localization release.

Hypotheses¶

#	Hypothesis	Status
H1	Universal lifecycle and identity behavior can be extracted from the Innoforce 1.5 package without weakening its human safety conditions.	superseded in part by A1: retain prompt/file identity semantics, discard executable locality/registry/locking implementation
H2	A classified manifest plus non-mutating comparison is sufficient for safe forward update and reviewed reverse promotion; an automatic two-way mirror is unnecessary.	superseded in part by A1: retain static manifest/policy and skill-driven gates, discard executable journal/update engine
H3	Practical templates can be neutralized while preserving the result-producing logic the owner considers essential, with company knowledge and branding fully excluded.	research-supported through restricted TI1; blocked-network render/privacy evidence remains mandatory during implementation
H4	Keeping the field-proven Russian user layer for the 1.5 core minimizes semantic sync drift; public English localization can remain a separate later task.	research-supported for 1.5; public history is public-only and machine-readable invariants remain language-neutral

Final Research Outcome¶

research/iter2/RES.md closed the configured two iterations with SUFFICIENT and no amendment proposals. Owner amendment A1 later superseded the executable portion of X2-refined after implementation evidence: custom locality/ACL/locking, persistent registry, executable maintenance journal/update and shipped self-test mechanics are rejected. Retained results are the static manifest/policy, prompt/file lifecycle and identity semantics, restricted TI1 templates, role boundaries, public-only version history, Russian 1.5 authority, non-mutating field comparison and independent review. The V1–V12 labels are replaced in the revised TS by proportionate static and scenario evidence for the no-code product.

Risks of Not Researching¶

Skipping research would assume that removal of company wording is mechanically safe, that template ownership is obvious, and that the source updater protects every downstream customization. Those assumptions are already contradicted by the mixed “neutral” package and by шаблоны/ currently being classified as a wholesale-replaced service directory. The likely cost is either a public data leak or a future forward update that destroys the very Innoforce overlay this task is meant to preserve.

Proposed RESEARCH Focus¶

Gather: construct a file/claim/ownership ledger across public 1.0 and field 1.2–1.5; locate every company, environment, language, hook and protected-state coupling.
Extract: compare maintenance configurations: whole-package replacement, core-plus-overlay manifest, generated distribution, stock-hash merge, and manual promotion.
Challenge: attack each configuration with private-data, custom-template, concurrent-change, legacy-profile, missing-capability and version-history scenarios.

Why Not Just...?¶

Why not copy the 1.5 folder verbatim? — It is functionally rich but materially non-neutral and would import company state and branding.
Why not keep public Assisted 1.0 and only link to Innoforce? — Users would not receive the proven lifecycle, identity, update or template improvements, and the public edition would remain unmaintained.
Why not make the two trees exact mirrors? — They have different legitimate owners: a public core and a private organizational overlay. Exact mirroring destroys one side or leaks the other.
Why not update Full TFW at the same time? — The owner expressly constrained the product change to Editions; mixing the two would dilute planning and create an unrelated authority change.

11. Strategic Insights (Planning) 🟢 FREE¶

#	Insight	Category	Source
S1	Innoforce knowledge is private organizational material and does not belong in the public Assisted package.	constraint	Owner clarification, 2026-08-30
S2	Practical templates are not incidental corporate baggage: they are how users reach result-first work and therefore belong in the public product after neutralization.	philosophy	Owner clarification, 2026-08-30
S3	Innoforce is the real practice ground for Assisted; public TFW should absorb the best verified logic so other users can arrive at the same working discipline.	philosophy	Owner clarification, 2026-08-30
S4	Future maintenance must work in both directions, but the reverse direction is conditional and cannot carry private overlay state.	process	Owner request, 2026-08-30
S5	The Full TFW core is explicitly outside the product scope even when its process creates task traces for this work.	constraint	Owner request, 2026-08-30
S6	The owner personally raised the scope budgets to `50 / 50 / 5000 / 50`; Codex synchronized the registered carriers and committed the change without taking authorship of the values.	process	Owner statement and commit `f3eb986`, 2026-08-30
S7	The owner delegated autonomous passage through ordinary research, TS, handoff, revision and review gates for this approved scope. That mandate does not approve amendments, scope expansion, budget overruns, push or tags; amendment proposals still return to the owner.	process	Owner mandate, 2026-08-30
S8	A safe maintenance bridge is not necessarily an automatic bridge: mixed public/downstream content requires reviewed reconstruction until ownership is structurally separated.	constraint	Research iteration 1 D12/C1, 2026-08-30
S9	“Machine-local” is a positive proof obligation, not a property implied by a conventional per-user directory name. Unknown locality must preserve usability through zero-write session state.	constraint	Research iteration 1 D7/C2, 2026-08-30
S10	Reusing one executor and one independent reviewer per phase preserves correction context without weakening role separation, provided every re-review reruns the full contract.	process	Research iteration 1 D11/C3, 2026-08-30
S11	Persistent locality is a revalidated result under a named threat model; it is never cached as a permanent machine fact.	constraint	Research iteration 2 D13/C1, 2026-08-30
S12	Public operation reports are privacy projections, not recovery evidence; private journal and terminal records remain separate and append-only.	constraint	Research iteration 2 D18/C3, 2026-08-30
S13	Automatic classified mutation is appropriate only for clean overlay-separated state; the present mixed field lineage uses non-mutating P6 reconstruction.	process	Research iteration 2 D19/C2, 2026-08-30
S14	A customizable template surface is safe for promotion only when its grammar is closed and its offline output is rendered and reviewed.	convention	Research iteration 2 D20/C4, 2026-08-30
S15	Capability loss must preserve the existing role lineage and filesystem trace; ambiguity is a reason to stop or complete manually, never to spawn a silent duplicate.	process	Research iteration 2 D21/C5, 2026-08-30
S16	TFW registration, identity, maintenance and update mechanics must be prompt/file-only; a simple human operation must not become a shipped Python or OS-security subsystem.	constraint	Explicit owner architecture ruling and amendment A1, 2026-08-30
S17	Three independent REVISE cycles and the actual Windows `icacls` hang are evidence that the research-derived runtime added disproportionate complexity and moved the product away from its intended prompt-based practice.	constraint	REVIEW rev1–rev3 and owner ruling, 2026-08-30

12. Amendment Log 🟢 APPEND-ONLY¶

#	Date	§	Type	Proposer	Proposed change	Evidence	Cost	Alternatives considered	Verdict
A1	2026-08-30	§3–§7	`SUPERSEDE`	owner (saubakirov)	TFW mechanics in Assisted become prompt/file-only. Delete executable identity/registration and maintenance/update/self-test runtime; keep `tfw-identity` as a Markdown procedure using ordinary agent file tools; keep static manifest/policy and a skill-driven `/tfw-update`; permit `шаблоны/build_a4.py` only as an artifact-template builder.	Explicit owner architecture ruling; field source is evidence rather than authority; field helper contains no `icacls`; the ACL/locality subsystem was added by this task; three REVISE cycles and the actual D11 Windows hang prove disproportionate runtime complexity.	Rework the approved HL and TS; delete two large product runtime files; rewrite dependent skills/docs/manifest/policy; invalidate and regenerate identity/maintenance evidence; perform another complete independent review; compact obsolete checkpoint history once at the final clean boundary.	Retain the field-level Python helper or repair/bound `icacls`; rejected by the owner because registration and workflow mechanics in TFW must not be code.	`✅ APPROVED — saubakirov, 2026-08-30`

HL — TFW_20260830-114238_ASSISTED15: Promote Field-Proven Assisted 1.5 into TFW Editions | 2026-08-30