[ticket-001] chore(governance): adopt new-project v0.16.1

[tom-sapletta-com]

Created by governed goal -a pull-request delivery.

[ifuri-validator-agent]

Deterministic Validator approval for exact head ca8e19b43440df3f9ace7c5d3d17858407cdcb42.

Ticket: ticket-001
Correlation ID: fixos-pr-1-ticket-001
Model: openrouter/z-ai/glm-5.2
Reviewed diff chunks: 36
Advisory LLM verdict: REQUEST_CHANGES
Advisory summary: Reviewed all 36 diff chunk(s). This chunk introduces a governance workflow, JSON schemas, and a branch lifecycle validation script. The GitHub Actions workflow uses pinned third-party action versions with SHA hashes, applies least-privilege permissions (contents: read, pull-requests: read), and writes snapshot files with restrictive 0o600 permissions. The branch_lifecycle_check.py script performs thorough input validation of the snapshot structure with exact field checks, repository format validation, ref name validation, and bounded array sizes. The .gitignore changes correctly re-include governance JSON files and the workflow file after excluding .json and .github/. No security issues, test failures, or blocking findings are present in this chunk. | This chunk adds a branch lifecycle governance checker and a JSON schema for change evaluation. The Python code validates repository snapshots for delete-branch-on-merge, internal PR head consistency, and orphaned branches, with appropriate error findings and structured reporting. The JSON schema is well-formed with proper constraints, conditional requirements, and type definitions. No security issues identified. All test checks are passing. | This chunk adds governance JSON schema definitions (change-evaluation, decision-record) and a Python required-checks validator script. The schema enforces strict validation with additionalProperties:false, required fields, and well-defined enums/patterns. The Python validator parses required-checks.json and compares against workflow YAML job names, with sensible error handling and no command execution or secret access. Test results all pass. | Decision record schema and parser/replay implementation for ticket-031. DSL parser is well-structured and the append-only integrity check uses content hashing. However, the verdict replay logic contains a regex/prefix-overlap issue (P-CORE-015 prefix match conflicts with P-CORE-010–014 range), and there are security-relevant concerns around ADVISORY verdict handling and input validation robustness. | This chunk adds a deterministic decision record derivation function and a CLI entrypoint for validating/replaying decision records, plus a diagnostics JSON catalog of governance error codes. The code derives verdicts from a change-evaluation schema without treating advisory LLM output as authority, and maps unknown verdicts safely to REQUEST_CHANGES. No security issues, command execution, or secret access are present in the visible code. | This chunk adds a diagnostic catalog (diagnostics.json), its JSON schema (diagnostics.schema.json), and an error documentation markdown file for remediation intent codes. The schema enforces a consistent structure for diagnostic codes with required message, remediation, and documentation fields. The documentation provides safe resolution guidance for remediation intent errors. No security issues, no failing tests. | This diff chunk adds governance error runbook documentation (GOV-TICKET-001, GOV-TICKET-ALLOCATION, GOV-WORKSPACE-LIFECYCLE, README) and begins the implementation of a deterministic governance_check.py validator. The runbooks are well-structured with required sections (Situation, Meaning, Safe resolution, Verification, Do not, Related rules) and contain sensible non-destructive remediation guidance. The Python code shows proper use of dataclasses, JSON loading, a report/finding system, regex patterns for secret detection, and work classification contract validation. No security issues, no command injection risks, and no secret exposure observed in the visible code. | Visible chunk contains governance validation logic for work classification and delivery constraints. It enforces strict, allowlist-based contracts (exact field sets, enumerated values, ordered rule identifiers, validated branch names and relative paths, integer range checks). Code is defensive and validation-focused with no security or correctness concerns. Tests all PASS. | This chunk contains validation logic for delivery intents including UI impact, architecture decisions, validation criteria, standard adoption, and pattern matching utilities. The code appears well-structured with proper input validation, regex-based commit SHA validation, and memoized recursive glob pattern matching. No security issues identified. | This chunk implements governance validation logic for history-order checks, policy validation functions, managed-lock verification, and managed-file digest comparison. The code uses safe path resolution (safe_repo_path), validated regex patterns, subprocess invocations with checked=True where appropriate, and structured error handling. No security issues identified. | This chunk contains governance validation logic for lock files, ticket intents, workstream limits, and dependency graphs. The code performs schema validation, path safety checks via safe_repo_path, and regex-based ticket ID validation. No security issues, test failures, or blocking findings are present. | Governance coordination logic for ticket dependency cycles, active relationship validation, workstream ownership, and scope overlap checks. Logic is sound with no security concerns, secrets, or dangerous operations visible in this chunk. | This diff chunk implements governance validation logic for Docker image immutability (SHA-256 pinning), stack profile markers, ticket content checks, secret detection in changed files, decision record validation, and delivery budget/timebox enforcement. The code appears well-structured with proper path safety checks, defensive error handling, and clear governance violation reporting. All test results in the provided data pass. | This chunk contains governance check logic for ticket delivery validation, including timebox enforcement, base SHA verification, architecture/budget checks, and change ticket selection. The code is well-structured with clear separation of concerns and proper error reporting. | This chunk contains governance logic for ticket state checks, workstream change scope enforcement, and external approval evidence validation. The code includes careful path-ownership validation, integration ticket coordination checks, and robust approval-evidence verification with external-file safeguards (O_NOFOLLOW, S_ISREG, is_relative_to checkout rejection). No security issues identified; tests pass. | Governance validation logic for approval evidence, standard adoption manifest/lock integrity, and managed file hash verification. Code validates trusted approval sources, verifies SHA-256 content digests, and enforces atomic standard adoption preconditions. Uses safe_repo_path and relative_pattern helpers appropriately for path safety. | This diff chunk adds governance check orchestration logic including change gate verification, SARIF/text rendering, argument parsing, manifest loading, and report writing. Path traversal protection via safe_repo_path and optional_repo_path is consistently applied. Resolved ticket output is correctly constrained to be outside the repository checkout. Error handling catches expected exceptions and reports them through the governance report system. No security issues, no test failures present. | This diff chunk introduces JSON Schema definitions for the governance intent and lock files, plus the base manifest. The schemas enforce strict validation with additionalProperties: false, constrained patterns for branches/globs/SHAs, and proper structural requirements. The manifest.base.json establishes governance configuration with conservative delivery limits (max 5 implementation files, max 2 affected components, 0 public interface changes). No security issues, command execution, or secrets handling are present in this configuration-only chunk. | This chunk adds governance manifest configuration, lock file hashes, and JSON schema definitions for a new project governance system. The code defines workstreams, delivery constraints, ticket lifecycle states, and approval evidence schemas. All test checks in the provided test_results_data are PASS, including multi-distro and multi-version tests. No security issues, secrets, or dangerous commands are present in this chunk. | Reviewed JSON schema definitions (governance manifest, remediation intent) and package manifest file mappings. Schemas enforce strict validation with proper path traversal prevention patterns and branch name validation. No security issues or code defects identified in this chunk. | This diff chunk defines JSON Schema definitions for a governance/analysis framework, including findings, actions, verifications, acceptance criteria, and LLM guidance. The schema is well-structured with proper constraints, validation patterns, and enumerated values. | This chunk introduces a remediation intent DSL template and the initial portion of a Python validator. The template explicitly forbids .env access in forbiddenPaths and restricts the LLM role to planning only. The Python validator code shown implements JSON loading, canonical digest computation, path safety checks (blocking absolute paths, Windows drive letters, and path traversal with ..), and begins cycle detection logic. No security issues, incomplete logic, or test failures are present in this visible chunk. | This chunk adds validation logic for a governance remediation DSL, including dependency cycle detection, source/objective/scope validation, findings validation with cross-references and cycle checks, verifications validation, and the beginning of actions validation. Code is well-structured with proper error accumulation, field validation, and dependency graph cycle detection using DFS. | This chunk contains validation logic for remediation intent actions and acceptance criteria, including deterministic verification enforcement, allowed/forbidden path checks, cycle detection, dependency closure enforcement, and risk constraints. Tests all pass. | This diff chunk adds a deterministic validation implementation for intent documents, including LLM guidance, todo2code, advisory analysis, and cross-reference checks. The code performs thorough structural validation with clear error reporting and appears to enforce important governance invariants such as dependency ordering, stale digest detection, and unresolved path handling only in DRAFT status. | This chunk of the diff (index 26/36) introduces remediation-intent rendering and todo2code analysis logic. The code demonstrates robust input validation via _require_valid with schema enforcement, and the todo2code analysis includes strong security guardrails: scope expansion detection, unauthorized deletion prevention, and plan gap detection. The logic is sound and well-structured. All tests passed across multiple platforms and Python versions. | This diff chunk adds governance tooling for remediation intent analysis (todo2code binding) and new JSON configuration files for required checks and stack profiles. The Python code correctly validates inputs, deduplicates findings, and handles blocking severities with proper exit codes. No command execution, secret access, or dangerous operations are present. All test checks in test_results_data are PASS. | This chunk adds governance work-classification DSL configuration and schema files, plus a workspace lifecycle audit Python script. The JSON schema is well-structured with proper validation constraints (additionalProperties: false, conditional if/then rules, enum restrictions). The Python script uses safe subprocess execution with timeouts and proper error handling. No security issues, no test failures in the provided results. | This diff chunk adds Python governance logic for workspace lifecycle auditing, including checkout inspection, ticket allocation validation, worktree discovery, and duplicate/linked-worktree detection. The code is well-structured with defensive error handling for git operations, JSON parsing, and file I/O. It uses subprocess-based git invocations without shell=True, validates inputs, and handles edge cases like unreadable state files and malformed JSON. No security issues identified. All test checks passed. | This chunk adds governance scaffolding (AGENTS.md, ticket index, governance-check scripts, project.bat wrapper, new-ticket.sh, TODO/goal updates). The code is policy/metadata configuration with fail-closed behavior. project.bat correctly validates manifest existence and Docker image SHA256 pining before running. governance-check.sh uses set -euo pipefail and resolves paths safely. No test failures in the provided test results. | This chunk implements the new-ticket allocation script with robust validation, clone-wide locking, and work classification contract enforcement. No blocking security issues found in the visible code. | This chunk adds shell scripts (project/readme.sh and ticket scaffolding tail) and ticket-001 documentation/logs. The readme.sh script includes path traversal guards and uses safe temp files with cleanup. The new-project.sh tail safely creates ticket scaffolds without generating human-owned files. Ticket-001 README and logs document governance adoption with explicit trust boundaries requiring independent approval before merge. No security issues, no test failures in provided data. | This chunk adds ticket-001 documentation (ai-codex.md, changelog.md, intent.json, preprompt.md) and a new scripts/runtime.sh entrypoint. The intent.json defines a governance adoption task with clear allowed/forbidden paths, non-goals, and validation criteria. scripts/runtime.sh begins with a Bash shim that validates Node.js 20+ then executes embedded JavaScript via stdin. No secrets, no destructive operations, no workflow modifications, and no test failures are present. The visible code shows defensive input parsing and error handling. | This chunk implements a JavaScript evaluation validator with policy, schema, binding, and hash validation. The logic appears sound and tests pass, but I identified a non-trivial input validation gap in the glob-to-regex path matching that could allow unintended path scope expansion, plus minor robustness concerns. | This chunk implements validation logic for a change-evaluation governance system, including Git range verification, criteria evaluation, approval binding, and verdict derivation. The code is well-structured with thorough diagnostic checks for merge-base consistency, path/commit set matching, criteria coverage, approval authority/staleness/binding verification, and verdict/completion consistency. | This chunk shows the tail end of a Node.js/TypeScript validation script that reads evaluation, intent, and manifest-lock JSON inputs, runs diagnostics, computes an evaluation digest, and emits a structured envelope plus markdown report. The logic is defensive (try/catch around input parsing), uses canonical serialization for the digest, and exits non-zero when merge is not allowed. No security issues, no test failures, and no blocking concerns are present in the visible code.
Advisory findings: replay_verdict uses rule.startswith("P-CORE-01") to catch a broad family, but this prefix also matches P-CORE-010 through P-CORE-014, which may be different rule types. The explicit set {"P-CORE-015", "C-CI-001", "C-DECISION-GATE"} plus the prefix is overlapping and ambiguous; a P-CORE-010 rule with different expected inputs would be forced through the check-gate path and either fail with a confusing error or return an incorrect verdict. This could cause incorrect governance decisions.; expected_verdict_from_rule fallback in replay_verdict allows any verdict string to be returned as the 'recomputed' verdict from inputs, bypassing actual deterministic rule replay. A malicious or malformed record could include expected_verdict_from_rule = APPROVE for any appliedRule and pass replay validation, defeating the security guarantee that ADVISORY verdicts are never trusted.; check_append_only does not validate that new decision blocks (beyond the previous count) are non-empty or well-formed before the hash comparison loop; a truncation or corruption of a new block could pass silently if it happens to produce the same count.; The expected_verdict_from_rule input allows verdict authority to be effectively overridden by the record author rather than recomputed from the rule, undermining the stated invariant that 'ADVISORY verdicts are never trusted' and that replay recomputes from INPUT + APPLIED_RULE. This is a trust-boundary violation in governance decision validation.; observed_checks entries are split on = with no length/content validation on the status value beyond .upper(); a crafted entry like check_name=GARBAGE would simply not match PASS/SUCCESS and yield REQUEST_CHANGES, but entries like =PASS (empty name) could map to empty-string key matching an empty required name, potentially causing false approvals if required_checks contains empty strings.; {'issue': 'Path matching glob expansion is not anchored to path segment boundaries', 'detail': 'The globToRegExp function converts ** to . without enforcing directory-separator semantics. Since pathAllowed controls whether a changed file path falls within the approved intent scope (GOV-SCOPE-001), an overly permissive regex could let an out-of-scope file path be accepted as in-scope. This is a governance boundary bypass risk, though exploitation depends on the specific allowedPaths values defined in the intent.'}
The LLM output above is advisory and was not used as the approval trust root.
Merge will be attempted after this approval when explicitly authorized.

Decision record (recomputable)

DECISION D-001-8261
TICKET ticket-001
HEAD_SHA ca8e19b43440df3f9ace7c5d3d17858407cdcb42
CORRELATION_ID fixos-pr-1-ticket-001
ACTOR agent:ifuri-validator-agent[bot]
APPLIED_RULE P-CORE-015
INPUT author_login = "tom-sapletta-com"
INPUT observed_checks = ["test-summary=PASS","test-fedora=PASS","test-ubuntu=PASS","test-alpine=PASS","test-debian=PASS","test-arch=PASS","governance / remote lifecycle=PASS","test (3.12)=PASS","test (3.11)=PASS","test (3.10)=PASS"]
INPUT required_checks = ["test (3.10)","test (3.11)","test (3.12)","test-summary"]
INPUT required_checks_source = "env/request"
INPUT reviewer_login = "ifuri-validator-agent[bot]"
VERDICT APPROVE AUTHORITY DETERMINISTIC
REJECTED REQUEST_CHANGES BECAUSE NO_UNSAFE_CHANGE_REASON_FOUND
ADVISORY llm_verdict = "REQUEST_CHANGES" MODEL "openrouter/z-ai/glm-5.2"
ASSERT VERDICT_AUTHORITY != "ADVISORY"