project-tiny-context-harness 0.2.53 → 0.2.55

package/assets/skills/plan_acceptance_checklist_compiler/SKILL.md

@@ -0,0 +1,427 @@
+---
+name: plan_acceptance_checklist_compiler
+description: Use when the user provides or references a long-task plan, Markdown plan, RFC, implementation plan, milestone plan, goal-mode task, or target-mode task and asks Codex to generate, audit, or sort a rigorous acceptance checklist or completion definition combined with project durable Context. English triggers include acceptance checklist for this plan, goal-mode prompt for this implementation plan, target-mode prompt for this plan, completion definition for this plan, long-task plan acceptance, and audit this plan for acceptance criteria. Chinese triggers must be tied to a plan, 方案, 计划, md, RFC, or implementation proposal, such as 整理这份方案，输出一份目标模式文本给我, 为这份方案生成验收清单, 方案验收清单, 长程任务方案验收, 实施计划验收清单, 结合项目 context 梳理方案验收, 为这份 md 生成目标模式验收文本, 把这份 md 整理成验收清单. Avoid standalone broad terms like goal mode, target mode, acceptance criteria, completion definition, 目标模式文本, 验收标准, or 完成定义 when no plan-like source is present. This Skill writes temporary plan/checklist artifacts under tmp/ty-context/plan-acceptance, compiles a generic acceptance checklist, and outputs a goal/target-mode prompt no longer than 4000 characters. It does not execute the plan, modify implementation code, run long validations, or mark goals complete.
+---
+
+# Plan Acceptance Checklist Compiler
+
+## Package-Managed Boundary
+
+This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `plan_acceptance_checklist_compiler` Skill directly in a consumer project.
+
+Project-specific acceptance rules belong in `project_context/**`, `DESIGN.md` when visual design facts are durable, or a separate project-local Skill. Keep this package-managed Skill business-agnostic.
+
+## Purpose
+
+Convert a given long-task plan into a strict, project-context-aware acceptance checklist and a short goal/target-mode execution prompt.
+
+The output answers:
+
+```text
+For this exact plan, what must be true before a future executor can honestly say the task is complete?
+```
+
+This Skill is generic. Do not embed business-specific rules, provider-specific rules, product-domain assumptions, artifact schemas, API names, UI names, status names, or one-off project logic in this Skill. If the user's plan contains a specific domain, derive acceptance items from that plan and the project Context during the current invocation only.
+
+## Required Outputs
+
+Every completed invocation must produce:
+
+1. A preserved copy of the plan under `tmp/ty-context/plan-acceptance/`.
+2. A rigorous acceptance checklist derived from the plan and relevant project Context.
+3. A goal/target-mode prompt the user can paste directly into Codex.
+
+Exception: if the Context confirmation gate below triggers, stop after materializing the plan and reading enough Context to explain the uncertainty. Ask the user for confirmation before producing the checklist or goal/target-mode prompt.
+
+The goal/target-mode prompt must be no longer than 4000 characters. Use the user's language when practical. For Chinese requests, use this shape:
+
+```text
+实施计划: tmp/ty-context/plan-acceptance/<plan>.md
+可多开agent，agent名额不够了就关掉不用的。
+<验收清单>
+```
+
+For English requests, use this shape:
+
+```text
+Plan: tmp/ty-context/plan-acceptance/<plan>.md
+You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
+<acceptance checklist>
+```
+
+This resource lifecycle line is part of the generated execution prompt. It authorizes parallel decomposition for the future executor while requiring unused agents to be closed when slots run low.
+
+## Non-Scope
+
+Do not execute the plan unless the user separately asks for execution.
+
+Do not modify product code, migrations, UI, API, tests, runtime artifacts, or durable Context while using this Skill.
+
+Do not run long validation, external probes, browser flows, cloud smoke tests, database writes, deployment commands, or other side-effect commands unless the user explicitly asks for validation execution.
+
+Do not mark any goal complete. This Skill defines acceptance; it does not complete acceptance.
+
+Do not lower the plan target to match current implementation.
+
+## Trigger Conditions
+
+Use this Skill when the user asks for any of the following:
+
+- Give a plan, Markdown file, RFC, milestone, or implementation proposal an acceptance checklist.
+- Combine project durable Context with a long-task plan to produce acceptance criteria.
+- Convert a long-range task plan into a checklist for Codex goal/target mode.
+- Generate a completion definition for "execute this plan until done."
+- Check whether a plan is missing acceptance conditions.
+- Combine user objective, plan steps, project Context, code entry points, and verification paths into an executable acceptance matrix.
+
+Typical trigger phrases:
+
+```text
+acceptance checklist for this plan
+goal-mode prompt for this implementation plan
+target-mode prompt for this plan
+completion definition for this plan
+long-task plan acceptance
+audit this plan for acceptance criteria
+整理这份方案，输出一份目标模式文本给我
+整理方案输出目标模式文本
+为这份方案生成验收清单
+方案验收清单
+长程任务方案验收
+实施计划验收清单
+结合项目 context 梳理方案验收
+为这份 md 生成目标模式验收文本
+把这份 md 整理成验收清单
+```
+
+Do not trigger from standalone broad phrases such as `goal mode`, `target mode`, `acceptance criteria`, `completion definition`, `目标模式文本`, `验收标准`, or `完成定义` unless the same user request also identifies a plan-like source.
+
+## Input Priority
+
+Build the checklist from these sources, in order:
+
+1. User's current instruction.
+2. The referenced or pasted plan.
+3. Relevant durable project Context under `project_context/**`.
+4. Repository guidance such as `AGENTS.md`, `README.md`, `DESIGN.md`, and relevant local Skills.
+5. Current code and tests, only to identify real surfaces, commands, routes, schemas, artifacts, entry points, and likely verification paths.
+6. Existing reports or artifacts, only to identify required evidence and invalidation risks. Existing artifacts are not proof unless the user explicitly asks to audit current completion.
+
+If plan and Context conflict, preserve the conflict in the checklist. Do not silently choose the easier side.
+
+## Step 1: Materialize The Plan Under `tmp/ty-context/plan-acceptance/`
+
+Before writing the checklist, write the user-specified plan into the repository `tmp/ty-context/plan-acceptance/` directory.
+
+Rules:
+
+- If `tmp/ty-context/plan-acceptance/` does not exist, create it.
+- If the user references a file outside `tmp/ty-context/plan-acceptance/`, copy its current content into `tmp/ty-context/plan-acceptance/<safe-plan-name>.md`.
+- If the user references a file already under `tmp/ty-context/plan-acceptance/`, use that path directly unless the user asks for a new copy.
+- If the user pasted the plan text, write the pasted plan exactly into `tmp/ty-context/plan-acceptance/<safe-plan-name>.md`.
+- Preserve the plan content. Do not summarize, normalize, reorder, translate, or edit it while materializing it.
+- Use a stable readable filename derived from the plan title, source filename, or user topic. Use lowercase letters, digits, hyphens, and `.md`.
+- If the source plan cannot be found or read, stop and report the missing source. Do not invent a plan.
+- The materialized plan is temporary execution input. It is not durable Context and not proof that any acceptance item passed.
+
+Recommended paths:
+
+```text
+tmp/ty-context/plan-acceptance/<plan-slug>.md
+tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md
+```
+
+## Step 2: Read Relevant Project Context
+
+Read only the Context needed for the plan's impacted surfaces. Use Context to identify what the project says the system should mean.
+
+Use code and tests to identify current implementation surfaces and verification commands. Code describes current state; it must not silently redefine the plan's completion definition.
+
+Extract:
+
+- Product or system contract.
+- Module boundaries.
+- API, data, artifact, runtime, UI, and test contracts.
+- Validation and deployment paths.
+- Security, privacy, redaction, and environment rules.
+- Known non-goals and forbidden dependencies.
+- Existing implementation entry points.
+
+## Step 3: Run The Context Confirmation Gate
+
+After reading the plan and relevant Context, decide whether generating an acceptance checklist would require guessing or silently accepting many durable fact changes. If yes, stop and ask the user to confirm details before continuing.
+
+Trigger this gate when any of these apply:
+
+- The plan appears to add or change many long-term facts, such as product ownership, module boundaries, API/schema semantics, data contracts, state semantics, verification/deployment entry points, UI information architecture, security/privacy rules, or cross-domain dependency rules.
+- The plan would likely require updates across multiple Context roles or areas, or more than a small number of durable Context files.
+- The plan conflicts with current Context and the conflict changes the completion definition rather than only implementation details.
+- The plan uses broad or strategic language whose meaning cannot be made falsifiable from the plan and Context alone, such as "rebuild the whole architecture", "unify every module", "production-grade", "fully integrated", "maximize capability", `重构整体架构`, `统一所有模块`, `生产级`, `长期方案`, `完全接入`, or similar.
+- The acceptance outcome depends on choosing between product/architecture alternatives that the user has not explicitly chosen.
+- External approvals, credentials, runtime environments, legal/compliance constraints, paid/provider access, or irreversible operational effects materially change what can be accepted.
+- You judge that proceeding would encode a durable assumption the user probably expects to review.
+
+When the gate triggers:
+
+- Do not compile the final checklist, write the checklist file, or generate the goal/target-mode prompt yet.
+- Ask 1-3 concise questions focused on the blocking durable assumptions.
+- Include the materialized plan path if already written.
+- State the specific Context files or Context roles that made confirmation necessary.
+- Offer a concrete default only when it is safe and reversible; otherwise ask for an explicit decision.
+- Resume from Step 2 after the user answers.
+
+Do not trigger this gate merely because the plan is large. If the Context impact is clear, bounded, and the checklist can represent the durable Context updates as acceptance items without guessing, continue.
+
+## Step 4: Compile The Acceptance Contract
+
+Before the detailed checklist, write a compact contract:
+
+```markdown
+## Acceptance Contract
+
+- Plan source: `tmp/ty-context/plan-acceptance/<plan>.md`
+- User objective: <objective>
+- Completion definition: <what must be true>
+- Core surfaces: <code/API/UI/data/runtime/artifact/test/context/etc.>
+- Explicit non-goals: <items>
+- External blockers: <accounts/session/credentials/network/cloud/manual approval/etc.>
+- Evidence standard: <accepted proof types>
+```
+
+If the plan uses broad words such as `all`, `complete`, `maximum`, `maximized`, `accepted`, `formal`, `production`, `real`, `current`, or `verified`, convert them into explicit inventory and evidence requirements.
+
+## Step 5: Build The Full Acceptance Checklist
+
+Treat the checklist as the set of falsifiable acceptance items a future executor must satisfy. It is not a progress log.
+
+Create a checklist table with these columns:
+
+```markdown
+| ID | Acceptance item | Source | Scope | Required evidence | Verification method | Fail / not accepted if |
+|---|---|---|---|---|---|---|
+```
+
+Column rules:
+
+- `ID`: stable ID such as `AC-01`; group by workstream if useful.
+- `Acceptance item`: one atomic condition that must be true.
+- `Source`: user instruction, plan section, Context file, code contract, schema, API, UI, test, or risk note.
+- `Scope`: one of `core`, `conditional`, `blocked-external`, `out-of-scope`, `nice-to-have`.
+- `Required evidence`: exact proof required.
+- `Verification method`: concrete command, check, inspection path, API call, UI check, artifact validation, or manual proof.
+- `Fail / not accepted if`: concrete invalidation case.
+
+Each item must be evidence-bound and falsifiable. Split combined requirements into separate rows.
+
+## Generic Acceptance Dimensions
+
+Include only dimensions relevant to the plan. Do not mechanically add irrelevant categories.
+
+Consider these generic dimensions:
+
+- Objective and completion definition.
+- Scope inventory and coverage.
+- Domain / project Context conformance.
+- Code implementation behavior.
+- API or interface contract.
+- Data model, schema, migration, or persistence.
+- Runtime state, configuration, session, credential, environment, or degraded behavior.
+- Artifact generation, schema, freshness, provenance, and acceptance.
+- UI or user-visible projection.
+- Async job, worker, scheduler, queue, or background process.
+- Security, privacy, redaction, secrets, and access control.
+- Observability, logs, diagnostics, and operator visibility.
+- Performance, timeout, boundedness, pagination, and resource budget.
+- Backward compatibility and non-regression.
+- Failure states, blocked states, retries, recovery, and next actions.
+- Unit, integration, contract, smoke, browser, cloud, or production-like validation.
+- Documentation or durable Context update, only when the plan requires a durable fact change.
+
+## Evidence Layer Separation
+
+For evidence-heavy or validation-heavy plans, keep these layers separate:
+
+```text
+infrastructure implemented
+runtime exercised
+evidence collected
+evidence accepted
+system surfaces reflect evidence
+final validation passed
+```
+
+Do not merge these layers unless the plan explicitly treats them as one.
+
+Examples of generic false completion:
+
+- Code exists, but runtime behavior was not exercised.
+- Artifacts exist, but current validators reject them.
+- Tests pass, but the required API/UI/runtime proof was not checked.
+- A partial sample ran, but the plan required full inventory coverage.
+- A document was updated, but the system state did not change.
+
+## Scope Labels
+
+Use these exact labels:
+
+- `core`: required to call the plan complete.
+- `conditional`: required only when a stated condition applies.
+- `blocked-external`: required for full completion but depends on unavailable external input.
+- `out-of-scope`: explicitly excluded by the user or plan.
+- `nice-to-have`: useful but not required; use sparingly.
+
+Do not mark an item out of scope only because it is difficult.
+
+## Conflict Handling
+
+If the plan, Context, and code disagree, add a conflict table:
+
+```markdown
+| Conflict | Plan says | Context says | Code currently does | Acceptance impact | Required resolution |
+|---|---|---|---|---|---|
+```
+
+Do not resolve conflict by silently following current code.
+
+## False-Completion Traps
+
+After the checklist, include traps that a future executor must not mistake for completion.
+
+Use generic wording. Do not add business-specific traps to the Skill itself.
+
+Template:
+
+```markdown
+## False-Completion Traps
+
+- <activity> is not enough unless <acceptance proof> also exists.
+- <partial proof> cannot prove <full acceptance item>.
+- <old/stale/mismatched evidence> cannot prove current completion.
+- <surface A> passing does not prove <surface B> unless the checklist links them.
+```
+
+## Suggested Execution Order
+
+Suggest an execution order that prioritizes the highest-risk proof first:
+
+1. Confirm scope inventory and completion definition.
+2. Confirm schemas/contracts and invalid evidence rules.
+3. Implement or repair the core path.
+4. Produce or inspect required runtime/artifact/API/UI evidence.
+5. Run contract/integration/regression checks.
+6. Run build/typecheck/lint/smoke checks.
+7. Update temporary checklist status only if the user asked for status tracking.
+
+Do not put low-signal checks before the core acceptance proof when the plan is evidence-driven.
+
+## Checklist Self-Test
+
+Every generated checklist must pass this self-test:
+
+```markdown
+## Checklist Self-Test
+
+- [ ] Every original plan section is mapped to at least one acceptance item or explicitly marked non-goal.
+- [ ] Every broad word such as all / maximum / complete / formal / production / verified is converted into inventory + evidence.
+- [ ] Every core item has a verification method.
+- [ ] Every evidence item defines invalid evidence.
+- [ ] Code, API, UI, data, runtime, artifacts, and tests are separated when they prove different things.
+- [ ] External blockers are separated from local remaining work.
+- [ ] Current implementation was not used to reduce the user's completion definition.
+- [ ] The checklist can be handed to another Codex session without hidden assumptions.
+```
+
+## Goal/Target-Mode Prompt Generation
+
+After compiling the checklist, produce a paste-ready goal/target-mode prompt.
+
+Hard requirements:
+
+- The prompt must be no longer than 4000 characters including line breaks.
+- The first line must identify the plan path.
+- Use `实施计划: <path>` for Chinese prompts and `Plan: <path>` for English prompts.
+- The second line must be a resource lifecycle instruction: `可多开agent，agent名额不够了就关掉不用的。` for Chinese prompts or `You may use multiple agents; if agent slots run low, close idle or unnecessary agents.` for English prompts.
+- The remaining content must be the acceptance checklist or a compact version of it.
+- The prompt must be self-contained enough for goal/target-mode execution.
+- Do not include explanatory preface inside the prompt.
+- Do not include Markdown tables inside the prompt if they make it too long.
+- Prefer short numbered items over verbose prose.
+- If the full checklist is too large, write the full checklist to `tmp/ty-context/plan-acceptance/<plan-slug>-acceptance-checklist.md`, then compress the goal/target-mode prompt while preserving all core acceptance categories.
+- The compact prompt may reference the full checklist path, but it must still include the core completion criteria directly.
+
+Recommended compact Chinese prompt shape:
+
+```text
+实施计划: tmp/ty-context/plan-acceptance/<plan-slug>.md
+可多开agent，agent名额不够了就关掉不用的。
+
+验收清单：
+AC1 <核心完成定义，包含验收证据>
+AC2 <范围/清单/覆盖要求>
+AC3 <Context/架构/边界要求>
+AC4 <核心实现行为要求>
+AC5 <数据/API/接口/契约要求>
+AC6 <运行态/配置/外部依赖/阻塞分类要求>
+AC7 <artifact/evidence/schema/freshness/provenance 要求>
+AC8 <UI/用户可见/API 投影一致性要求>
+AC9 <安全/隐私/脱敏/secret 要求>
+AC10 <测试/构建/集成/smoke/回归要求>
+AC11 <文档/Context 更新要求，仅在计划要求时执行>
+AC12 完成前审计：逐条对照实施计划；每个 core 项必须有当前证据；未跑验证必须明示；有可继续执行的 core 项不得标记完成；外部阻塞必须写明原因、影响和下一步。
+
+禁止把以下内容当完成：只改代码、只更新计划、只跑部分测试、只生成旧/部分/不被当前契约接受的证据、只完成基础设施但未完成验收证据、API/UI/数据/测试之间仍矛盾。
+```
+
+Recommended compact English prompt shape:
+
+```text
+Plan: tmp/ty-context/plan-acceptance/<plan-slug>.md
+You may use multiple agents; if agent slots run low, close idle or unnecessary agents.
+
+Acceptance checklist:
+AC1 <core completion definition with required evidence>
+AC2 <scope inventory and coverage>
+AC3 <Context / architecture / boundary conformance>
+AC4 <core implementation behavior>
+AC5 <data / API / interface / contract requirements>
+AC6 <runtime / configuration / external dependency / blocker classification>
+AC7 <artifact / evidence / schema / freshness / provenance requirements>
+AC8 <UI / user-visible / API projection consistency>
+AC9 <security / privacy / redaction / secret handling>
+AC10 <test / build / integration / smoke / regression requirements>
+AC11 <documentation / Context updates only when required by the plan>
+AC12 Final audit: compare every item against the plan; every core item needs current evidence; missing validation must be stated; any executable core item left open means the task is not complete; external blockers need cause, impact, and next action.
+
+Do not count these as completion: code-only changes, plan-only updates, partial tests, stale or partial evidence, infrastructure without acceptance proof, or contradictions between API/UI/data/tests.
+```
+
+Before final response, check the prompt length. If it exceeds 4000 characters, compress it and check again.
+
+## Final Response Requirements
+
+For completed checklist runs, the final response must include:
+
+- `tmp/ty-context/plan-acceptance/` plan path.
+- Full checklist path if a full checklist file was written.
+- The paste-ready goal/target-mode prompt in a code block.
+- Any unresolved ambiguity that affects checklist accuracy.
+
+If the Context confirmation gate triggers, the response must ask for the needed confirmation instead of including the checklist or goal/target-mode prompt.
+
+Do not claim that any acceptance item has passed unless the user explicitly asked for a current completion audit and current evidence was inspected.
+
+## Forbidden Behaviors
+
+Do not include concrete business-domain logic in this Skill.
+
+Do not hardcode project-specific provider names, API names, UI names, artifact paths, schemas, statuses, or commands in this Skill.
+
+Do not execute the generated goal/target-mode prompt.
+
+Do not use the checklist to mark the task complete.
+
+Do not hide missing source files, ambiguous plan scope, or external blockers.
+
+Do not rewrite the user's plan while copying it into `tmp/ty-context/plan-acceptance/`.
+
+Do not use a short sample, stale artifact, old result, or current implementation convenience to reduce a plan that asked for full completion.

package/assets/tools/validate_context.py

@@ -167,7 +167,7 @@ def validate_manifest(errors):
     roles = {}
     if not manifest_path.exists():
         if schema_requires_manifest():
-            errors.append("missing project_context/context.toml; run sdlc-harness upgrade to create the Schema v4 Context graph manifest")
+            errors.append("missing project_context/context.toml; run ty-context upgrade to create the Schema v4 Context graph manifest")
         return roles
     manifest = parse_manifest(manifest_path, errors)
     if not manifest["areas"]:

package/dist/cli.js

@@ -7,6 +7,6 @@ async function main() {
 }
 main().catch((error) => {
     const message = error instanceof Error ? error.message : String(error);
-    console.error(`sdlc-harness: ${message}`);
+    console.error(`ty-context: ${message}`);
     process.exitCode = 1;
 });

package/dist/commands/check-modularity.js

@@ -23,21 +23,27 @@ export async function checkModularity(args) {
             files: parsed.files,
             limit: parsed.limit
         });
-        console.log(`check-modularity audited=${report.files.length} warning=${report.warnings.length} limit=${report.limit}`);
+        console.log(`check-modularity audited=${report.files.length} warning=${report.warnings.length} limit=${report.limit} waived=${report.waivedWarnings.length}`);
         if (report.files.length === 0) {
             console.log("No handwritten source files matched the selected scope.");
         }
         for (const file of report.files) {
-            const prefix = file.overLimit ? "over-limit" : "ok";
+            const prefix = file.overLimit && file.waived ? "waived" : file.overLimit ? "over-limit" : "ok";
             console.log(`${prefix}: ${file.relativePath} ${file.lines} lines`);
         }
+        for (const error of report.errors) {
+            console.error(`error: ${error}`);
+        }
         for (const warning of report.warnings) {
             console.warn(`warning: ${warning}`);
         }
+        for (const waiver of report.waivedWarnings) {
+            console.warn(`waived: ${waiver}`);
+        }
         if (report.warnings.length > 0) {
-            console.warn("warning: over-limit touched files need a split, or final handoff should include `Modularity: exception documented` with file, reason and future boundary.");
+            console.warn("warning: over-limit touched files need a split or, when modularity.policy is scoped_waivers, a valid <harnessRoot>/config.yaml modularity waiver with file, reason and future split boundary.");
         }
-        if (report.warnings.length > 0 && parsed.failOnWarning) {
+        if (report.errors.length > 0 || (report.warnings.length > 0 && parsed.failOnWarning)) {
             process.exitCode = 1;
         }
     }
@@ -127,11 +133,13 @@ function parseLimit(value) {
     return limit;
 }
 function helpText() {
-    return `sdlc-harness check-modularity:
+    return `ty-context check-modularity:
   check-modularity --touched [--limit 300] [--fail-on-warning]
   check-modularity --file <path> [--file <path> ...] [--limit 300] [--fail-on-warning]
   check-modularity --base <ref> [--limit 300] [--fail-on-warning]
 
 Audits selected handwritten source files for physical line-count risk.
-The default is warning-only; --fail-on-warning lets projects opt into CI enforcement.`;
+The default is warning-only; --fail-on-warning lets projects opt into CI enforcement.
+Generated configs default to modularity.policy: strict_except_generated; omitted policy is treated as scoped_waivers for compatibility.
+Over-limit files can be waived only through <harnessRoot>/config.yaml modularity.waivers when policy is scoped_waivers.`;
 }

package/dist/commands/export-context.js

@@ -136,14 +136,14 @@ function printWarnings(warnings) {
     }
 }
 function helpText() {
-    return `sdlc-harness export-context:
-  export-context --full [--output tmp/sdlc/context-exports/<name>.md] [--check]
-  export-context --code [--output tmp/sdlc/context-exports/<name>.md] [--check]
+    return `ty-context export-context:
+  export-context --full [--output tmp/ty-context/context-exports/<name>.md] [--check]
+  export-context --code [--output tmp/ty-context/context-exports/<name>.md] [--check]
   export-context --all [--check]
 
 Creates temporary Markdown artifacts for copying or external-tool ingestion.
 --full exports the project Context summary as a full-project-context artifact.
 --code exports one current implementation snapshot as a code-level-implementation artifact.
 --all exports both default artifacts in one command.
-The artifact must stay under tmp/sdlc/context-exports/** and must not be referenced from project_context/context.toml.`;
+The artifact must stay under tmp/ty-context/context-exports/** and must not be referenced from project_context/context.toml.`;
 }

package/dist/commands/index.js

@@ -16,11 +16,12 @@ export const commands = {
     "export-context": exportContext,
     validate,
     "validate-context": (args) => validate(["validate-context", ...args]),
+    "validate-code-modularity": (args) => validate(["validate-code-modularity", ...args]),
     "validate-harness": (args) => validate(["validate-harness", ...args]),
     package: packageSource
 };
 export function help() {
-    console.log(`sdlc-harness commands:
+    console.log(`ty-context commands:
   init [--adopt] [--harness-folder <path>]
                        Initialize/adopt a project; without --harness-folder, choose target agent first
   sync                 Refresh managed assets; refuses when upgrade migrations are pending
@@ -30,9 +31,11 @@ export function help() {
   check-modularity --touched|--file <path>|--base <ref> [--limit 300] [--fail-on-warning]
                        Warn when selected handwritten source files exceed a line-count limit
   export-context --full|--code|--all [--output <path>] [--check]
-                       Export a temporary Context summary or code implementation Markdown artifact
-  validate <gate>      Run a Harness validation gate (Minimal Context only)
-  validate-context     Validate Minimal Context fact-source recoverability
-  validate-harness     Compatibility alias for validate-context
+                       Export a temporary Context summary or code implementation Markdown artifact
+  validate <gate>      Run a Harness validation gate
+  validate-context     Validate Minimal Context fact-source recoverability
+  validate-code-modularity
+                       Enforce touched handwritten source file modularity
+  validate-harness     Run validate-context and validate-code-modularity
   package <subcommand> Maintain package canonical source`);
 }

package/dist/commands/init.js

@@ -20,7 +20,7 @@ export async function init(args) {
     const configuredRoot = await resolveInitHarnessRoot(projectRoot, args);
     if (configuredRoot) {
         await writePackageHarnessRoot(projectRoot, configuredRoot);
-        console.log(`configured package.json sdlcHarness.harnessFolderName=${JSON.stringify(configuredRoot)}`);
+        console.log(`configured package.json tyContext.harnessFolderName=${JSON.stringify(configuredRoot)}`);
     }
     const report = await runInit(projectRoot, { adopt, force });
     for (const line of report) {

package/dist/commands/package-source.js

@@ -18,7 +18,7 @@ export async function packageSource(args) {
         console.log("package source OK");
         return;
     }
-    console.log(`sdlc-harness package commands:
+    console.log(`ty-context package commands:
   sync-source    Update package canonical assets from this source workspace
   check-source   Verify package canonical assets match this source workspace`);
 }

package/dist/commands/upgrade.js

@@ -55,7 +55,7 @@ function parseArgs(args) {
     return options;
 }
 function printHelp() {
-    console.log(`sdlc-harness upgrade:
+    console.log(`ty-context upgrade:
   upgrade              Run safe migrations, sync managed assets and doctor
   upgrade --check      Print the upgrade plan without writing files
   upgrade --check --json

package/dist/lib/config.js

@@ -9,12 +9,16 @@ export function defaultConfig(root) {
             package: CANONICAL_CORE_PACKAGE,
             schema_version: CURRENT_SCHEMA_VERSION
         },
+        modularity: {
+            limit: 300,
+            policy: "strict_except_generated"
+        },
         managed_files: [
             { path: "AGENTS.md", strategy: "merge-block" },
             { path: "Makefile", strategy: "merge-block" },
             { path: harnessPath(root, "skills"), strategy: "managed" },
-            { path: harnessPath(root, "pjsdlc_managed", "context_templates"), strategy: "managed" },
-            { path: harnessPath(root, "pjsdlc_managed", "make", "sdlc-harness.mk"), strategy: "managed" },
+            { path: harnessPath(root, "ty-context-managed", "context_templates"), strategy: "managed" },
+            { path: harnessPath(root, "ty-context-managed", "make", "ty-context.mk"), strategy: "managed" },
             { path: "tools", strategy: "managed" },
             { path: ".github/workflows/harness.yml", strategy: "create-if-missing" }
         ],
@@ -46,6 +50,7 @@ export function normalizeConfig(value, root = ".agent") {
             package: value.core?.package ?? fallback.core.package,
             schema_version: value.core?.schema_version ?? fallback.core.schema_version
         },
+        modularity: value.modularity,
         managed_files: value.managed_files ?? fallback.managed_files,
         never_overwrite: value.never_overwrite ?? fallback.never_overwrite
     };

package/dist/lib/constants.d.ts

@@ -1,3 +1,3 @@
 export declare const CANONICAL_CORE_PACKAGE = "project-tiny-context-harness";
 export declare const CURRENT_SCHEMA_VERSION = "4";
-export declare const CANONICAL_NPX_COMMAND = "npx --yes --package project-tiny-context-harness@latest sdlc-harness";
+export declare const CANONICAL_NPX_COMMAND = "npx --yes --package project-tiny-context-harness@latest ty-context";

package/dist/lib/constants.js

@@ -1,3 +1,3 @@
 export const CANONICAL_CORE_PACKAGE = "project-tiny-context-harness";
 export const CURRENT_SCHEMA_VERSION = "4";
-export const CANONICAL_NPX_COMMAND = `npx --yes --package ${CANONICAL_CORE_PACKAGE}@latest sdlc-harness`;
+export const CANONICAL_NPX_COMMAND = `npx --yes --package ${CANONICAL_CORE_PACKAGE}@latest ty-context`;

package/dist/lib/context-export.js

@@ -8,7 +8,7 @@ import { harnessRoot } from "./harness-root.js";
 import { SAFE_EXAMPLE_FILE_NAMES, shouldExcludeRelativePath, shouldIncludeCodeFile, toPosix } from "./source-files.js";
 const execFileAsync = promisify(execFile);
 const EXPORT_HEADER = "Export artifact. Do not reference from project_context/context.toml.";
-const DEFAULT_EXPORT_DIR = "tmp/sdlc/context-exports";
+const DEFAULT_EXPORT_DIR = "tmp/ty-context/context-exports";
 const CODE_EXPORT_FILE_NAME = "code-level-implementation.md";
 const MAX_TREE_ENTRIES = 300;
 const MAX_TREE_DEPTH = 4;
@@ -187,17 +187,17 @@ function resolveOutputPath(projectRoot, requestedOutput, now, mode) {
     const absoluteOutput = path.resolve(projectRoot, rawOutput);
     const relative = repoRelative(projectRoot, absoluteOutput);
     if (relative.startsWith("..") || path.isAbsolute(relative)) {
-        throw new Error("export-context --output must stay inside the workspace; use tmp/sdlc/context-exports/<name>.md");
+        throw new Error("export-context --output must stay inside the workspace; use tmp/ty-context/context-exports/<name>.md");
     }
     const normalized = toPosix(relative);
     if (normalized === "project_context" || normalized.startsWith("project_context/")) {
-        throw new Error("export-context output is a temporary artifact; use tmp/sdlc/context-exports/** instead of project_context/**");
+        throw new Error("export-context output is a temporary artifact; use tmp/ty-context/context-exports/** instead of project_context/**");
     }
     if (!normalized.startsWith(`${DEFAULT_EXPORT_DIR}/`)) {
-        throw new Error("export-context only writes temporary artifacts under tmp/sdlc/context-exports/**");
+        throw new Error("export-context only writes temporary artifacts under tmp/ty-context/context-exports/**");
     }
     if (!normalized.endsWith(".md")) {
-        throw new Error("export-context --output must be a Markdown file under tmp/sdlc/context-exports/**");
+        throw new Error("export-context --output must be a Markdown file under tmp/ty-context/context-exports/**");
     }
     return absoluteOutput;
 }