Skip to content

Releases: adand-91/gpt-6-astra-skill

GPT-6 Astra Skill Optimizer v1.0.0

Choose a tag to compare

@adand-91 adand-91 released this 09 Sep 02:14

GPT-6 Astra Skill Optimizer v1.0.0

What it is

An independent, Skill-only audit workflow for GPT-6 Astra. It jointly audits one selected project
and its explicitly related Skills, then proposes evidence-backed improvements.

Included

  • Official-source register for GPT-6 Astra model guidance, Skills, and plugin review rules.
  • Audits for initiative, focused clarification, instruction priority, output format, delegation,
    verification, context, authority, security, and maintenance.
  • Fact/inference/unknown separation and a structured finding schema.
  • Read-only-by-default behavior with an exact path allowlist before authorized edits.
  • Five positive and five negative/boundary release-candidate cases.

Evidence and limits

Sources are retrieved guidance and audit evidence, not model-training data. The Skill does not train
or modify GPT-6 Astra and cannot prove project quality, profitability, release approval, or safety.
Open-ended Skill enumeration, private evidence exposure, installation, publication, and external
messaging remain separately authorized actions.

v0.2.0-beta.1 — Daily and weekly review scaffolds

Choose a tag to compare

@adand-91 adand-91 released this 07 Sep 03:47

Beta 1 adds installed daily and weekly review scaffolds. Previously, review-init only created one-time audit scaffolds; it now supports audit, daily, and weekly while preserving the existing explicit-input and analysis-only boundaries.

What changed

  • Daily and weekly modes calculate the last completed local one-day/seven-day window using an explicit IANA timezone, optional --at timestamp, and configurable --boundary-hour (default 8).
  • Explicit --start / --end windows remain available for all modes. Audit still requires them.
  • DST gaps advance to the first valid local minute; repeated boundary times use the first occurrence.
  • Output stays private and no-overwrite. The command does not retrieve history, fill in findings, schedule reviews, or authorize project edits.

Try it

Install the attached wheel in an activated virtual environment, then run:

python -m pip install requirement_ledger-0.2.0b1-py3-none-any.whl
requirement-ledger review-init --mode daily --target example-project --timezone Asia/Shanghai --at 2026-09-07T09:00:00+08:00 --output daily.md
requirement-ledger review-check daily.md

Use --mode weekly for a seven-day window. A passing review-check validates the scaffold format; it does not prove a completed review or verified findings.

Verification

  • 138 source tests and 138 extracted-sdist tests passed locally.
  • Clean wheel/sdist installations passed all three modes, private permissions, no-overwrite, invalid-input and deterministic Demo checks.
  • Exact commit a279f673e1febe809bcf6dc8c4765898d1ee2750 passed public CI: Python 3.10–3.13 on Linux, macOS and Windows, plus built-artifact/security smoke.
  • Attached SHA256SUMS covers both fresh release artifacts.

This is a non-latest prerelease. Stable v0.1.1 remains available. Later Beta/RC/Jarvis features and the recently observed project-takeover UX improvements are not part of this release.

中文

Beta 1 将安装版 review-init 从只支持一次性审查扩展为支持审查、日报和周报,能够按时区计算最近完整的一天或七天窗口,并处理夏令时边界。它生成私有空白复盘文档,不自动读取历史、填写结论或定时执行。三平台 CI 和干净安装验证已通过。本版是预发布版,不包含后续 Jarvis 接管体验改进。

v0.2.0-alpha.3 — modern Codex rollout normalisation

Choose a tag to compare

@adand-91 adand-91 released this 03 Sep 02:37

v0.2.0-alpha.3 — modern Codex rollout normalisation

Problem closed

Alpha 2 bound one selected Codex export safely, but its semantic adapter understood only a narrow
legacy event surface. Current paginated rollouts persist structured item_completed lifecycle
records, can repeat snapshots for the same item, and may record a late item after task_complete.
Treating every snapshot as a new event or inferring completion from prose would produce a false
history.

User-visible increment

codex-scan now emits codex-input-envelope/v2 with a
codex-modern-normalization/v1 section. For the official TurnItem allowlist implemented by this
candidate, it:

  • preserves the first physical-record position of each completed item;
  • coalesces repeated snapshots by (turn_id, item.id) and lets the latest valid snapshot supply
    the final structured status;
  • keeps the same item ID in different turns separate;
  • records task_complete as an ordered turn terminal without claiming that no late item follows;
  • never content-deduplicates ordinary messages or tool events and never infers completion from
    natural language;
  • records exact structured automation, delegation, Subagent, system, and non-evidence metadata
    exclusions with balanced physical-record accounting.

Tuple identity is encoded as canonical JSON rather than delimiter concatenation. Control-bearing
IDs, future or malformed UserInput blocks, invalid status/type pairs, and normalization counts
that do not conserve against recognized records fail closed. The work boundary is 64 MiB and
1,000,000 physical records.

The envelope stores only fixed item kinds/statuses, physical positions, timestamps, counts, and
source-bound opaque identifiers. It does not store raw turn/item IDs, commands, outputs, Skill
names, Skill paths, file names, absolute paths, or source text.

Named-Skill proof

The release fixture uses an official UserInput::Skill block naming a real local Skill shape
alongside a text instruction. The private evidence can retain the selected user text, as designed;
the non-textual envelope retains neither the Skill name nor its path. This is a maintainer-owned
fixture, not external-user adoption evidence.

Compatibility and limits

  • The frozen v0.1 scan command keeps its legacy parser and inclusive --until behaviour.
  • codex-scan keeps Alpha 2's one-file, 64 MiB, scoped, half-open [start,end), same-byte,
    non-overwrite boundary.
  • It additionally stops above 1,000,000 physical records, even if the byte cap is not reached.
  • Unknown record types, unknown TurnItem types, invalid final statuses, malformed records,
    timestamp failures, budget drops, or identifier/type conflicts mark the source incomplete.
  • The normaliser preserves physical JSONL order; it does not reorder records by optional rollout
    ordinal or claim a canonical full-thread reconstruction.
  • The allowlist follows current first-party protocol shapes and is explicitly partial-alpha.3;
    Codex remains non-exhaustive and can evolve.
  • Deterministic opaque IDs are private binding aids, not anonymity guarantees. Low-entropy values
    may remain guessable or linkable.
  • One selected export is not complete target history. This release does not discover tasks,
    read ~/.codex, call a host history API, or grant implementation/publication authority.

Release gate

The annotated tag and public assets are created only from the exact commit that passes the full
Python 3.10–3.13 Linux/macOS/Windows matrix plus built-artefact and fail-closed security smoke.
The release remains a non-latest prerelease; it does not authorise promotion, programme
application, or later versions.

v0.2.0-alpha.2 — Bounded Codex input

Pre-release

Choose a tag to compare

@adand-91 adand-91 released this 01 Sep 04:12

v0.2.0-alpha.2 — bounded Codex input

Problem solved

The generic v0.1 scanner accepts explicit files, but it does not prove that a Codex run stayed
inside a user-approved export directory or explain which physical records were included or
excluded. A caller could also mistake one file for complete task history.

User-visible increment

codex-scan accepts one explicit Codex JSONL file and requires a scope root, non-path target and
task references, an offset-aware half-open window, and an IANA timezone. It captures the source
once, hashes and parses those exact bytes, and embeds a private codex-input-envelope/v1 in the
ordinary private evidence bundle.

The envelope contains only fixed metadata: digest, byte count, record counts, hashed target/task
bindings, window metadata, inclusion/exclusion codes, and coverage states. It contains no source
text, file name, or path. The surrounding evidence remains private and may contain selected user
text.

Safety gates

  • one file only; no directory or discovery mode;
  • scope root cannot be a filesystem root or the user home itself;
  • parent traversal, scope escape, hard links, and ordinary symlink/reparse components fail closed;
  • capture is limited to 64 MiB and identity/content metadata is checked around the read;
  • output is no-overwrite and 0600 where supported;
  • an event at until is excluded by the [start,end) contract;
  • record accounting is balanced, while semantic normalization and target-history completeness
    remain explicitly partial/unknown.
  • missing/invalid timestamps, malformed, unsupported, or oversized records make the selected
    source incomplete and block downstream confirmation.

Compatibility and limits

The v0.1 scan command and schemas remain available. codex-scan is a new opt-in path; it does not
search ~/.codex, call a host task API, normalise every modern Codex event, or prove that the
selected export contains the entire target history. Windows relies on reparse and repeated
identity checks where POSIX dir_fd guarantees are unavailable.
On macOS, Apple's root-owned /var, /tmp, and /etc compatibility aliases are deliberately
mapped to fixed /private targets. Hashing and parsing use the same captured bytes, but concurrent
source-path stability is only metadata-checked best effort, not an atomic snapshot. The command
starts no network client; it does not determine whether a selected filesystem is remotely mounted.
The enclosing v0.1 bundle's legacy network_used: false field has that same narrow meaning.
Deterministic target/task SHA-256 values bind references but do not anonymise low-entropy values;
such values may be guessed or linked across private bundles.

Release gate

The annotated tag and public assets are created only from the exact commit that passes the full
Python 3.10–3.13 Linux/macOS/Windows matrix plus built-artefact and fail-closed security smoke.
The release remains a non-latest prerelease; it does not authorise promotion or later versions.

Requirement Ledger AI v0.2.0-alpha.1 — Named-target audit

Choose a tag to compare

@adand-91 adand-91 released this 30 Aug 03:50

Requirement Ledger AI v0.2.0-alpha.1

This is the first public v0.2 prerelease: an installable, offline starting point for one explicit
Codex conversation, Agent Skill, or project audit.

Full release notes ·
中文更新说明 ·
10-day update map

What changed

  • requirement-ledger review-init --mode audit creates a private, no-overwrite audit scaffold for
    one explicit target, half-open time window, and IANA timezone.
  • requirement-ledger review-check REPORT mechanically validates report structure, evidence
    labels, candidate state, source fields, coverage, timezone, and authorisation.
  • The standalone checker delegates to the packaged implementation, so the contract has one source
    of truth.
  • The scaffold starts with zero retrieved sources, incomplete coverage, and analysis-only
    authority. It cannot masquerade as a completed diagnosis.
  • Windows installs tzdata conditionally so IANA timezone validation works consistently on every
    supported operating system.
  • Bilingual changelog, release notes, host contract, reference templates, and a gate-driven
    ten-day update map now distinguish shipped capability from future work.

Problems solved

Before Alpha 1
No installable, target-specific starting point for a named Skill or project audit. One command creates a bounded private audit document with explicit unknowns.
A Markdown report could look complete while required evidence or safety fields were missing. The checker returns a failing exit code and actionable findings.
A generated review could overwrite existing work or use broad permissions. Output is no-overwrite and mode 0600 where supported.
Missing Windows timezone data was misreported as an invalid IANA name. A Windows-only tzdata dependency fixes valid names; no-dependency installs get an actionable error.
Product language could be mistaken for automatic history scanning or editing. The scaffold records zero sources, incomplete coverage, and analysis-only authority.

Install and verify

python3 -m pip install \
  https://github.com/adand-91/requirement-ledger/releases/download/v0.2.0-alpha.1/requirement_ledger-0.2.0a1-py3-none-any.whl

requirement-ledger review-init \
  --mode audit \
  --target my-agent-skill \
  --start 2026-08-29T00:00:00+08:00 \
  --end 2026-08-30T00:00:00+08:00 \
  --timezone Asia/Shanghai \
  --output /tmp/my-agent-skill-audit.md

requirement-ledger review-check /tmp/my-agent-skill-audit.md

Expected result: WROTE_PRIVATE_AUDIT_SCAFFOLD, then REVIEW_REPORT_VALID.

Release evidence

  • Tagged commit: 243b01ac5be88825ec4a1f4f9c5cec3b2841a90e
  • Public CI: run 33291029715 —
    Python 3.10–3.13 on Linux, macOS, and Windows plus built-artefact/security smoke all passed.
  • Source and extracted-sdist suites: 113 tests passed.
  • Wheel SHA-256: 3123b30db1610e0b930c0d0f26a3a24ec3dbe47917d5da7d1f7c3b800dac615b
  • Sdist SHA-256: 1e5407f5f48d8bdd19f18749aa6bc978002415a90061426cf5bef9b40103ae05
  • SHA256SUMS is attached and uses basenames only.

Known limits

This Alpha does not scan Codex history, the home directory, or a Git project. It does not run
project code, edit a target, schedule reviews, or grant implementation authority. A Codex host
must separately select and supply bounded context.

Daily/weekly CLI initialisation, modern Codex export parsing, candidate carry-over, exact-byte
report handoff binding, and autonomous edits are not part of this release.


中文摘要

这是第一个公开 v0.2 预发布版:针对一个点名 Codex 对话、Agent Skill 或项目,提供可安装、离线、
私有的一次性审查起点。

  • 新增 review-init --mode audit 私有审查骨架和 review-check 机械校验器。
  • 解决“报告看似完整但缺证据/授权字段”“覆盖已有文件”“Windows 缺时区数据库”等问题。
  • 113 项源码与 sdist 测试、Linux/macOS/Windows 跨平台 CI、构建制品和安全冒烟全部通过。
  • 当前不会自动读取历史、自动修改、初始化日报/周报或执行 GitHub 动作;这些边界均保留为后续门禁。
  • 十天目标是稳定、可用的 v0.2.0,不是按天制造空版本;任何门禁失败都会停止发版。

Requirement Ledger AI v0.1.1

Choose a tag to compare

@adand-91 adand-91 released this 28 Aug 09:26

v0.1.1 — Requirement Ledger AI discovery and Skill walkthrough

Status: released on 2026-08-28 from commit d07c13f91b119acf55135a504b8ba993f6b1aaf9; public CI run 33159107505 passed before tagging.

What changed

  • The product is now presented as Requirement Ledger AI, an AI project and Skill feedback
    loop for Codex, Claude Code, and any Git project.
  • README discovery metadata, badges, search terms, and first-use framing now make the two primary
    jobs explicit: improving an agent Skill and improving an ordinary software project.
  • A wholly synthetic, reproducible Skill walkthrough demonstrates the complete boundary:
    explicit evidence → conservative analysis → reviewable plan → separately authorised host edit
    → externally run, digest-bound before/after oracle → improved validation.
  • The new bilingual roadmap defines the fifteen-day technical launch track through v0.2.0,
    v1.0.0-rc.1, and v1.0.0, while keeping autonomous edits and GitHub actions outside v1.
  • Package and record versions now share one authoritative __version__ source.

Compatibility and safety

  • No CLI command, schema, repository slug, package name, or console command changed.
  • The CLI still does not discover private histories, execute project code, edit a Skill or
    worktree, install project dependencies, access a network, or perform GitHub/account actions.
  • One local conversation and oracle do not establish upstream attribution; the walkthrough's
    issue scope remains unknown.
  • The Skill edit in the walkthrough belongs to an authorised host such as Codex or Claude Code,
    not to Requirement Ledger itself.

Verified release-candidate evidence

  • The documented Skill case produced baseline exit 1, after exit 0, and a validation result
    of improved while keeping the candidate scope unknown and raw failure text out of the report.
  • 97 unit tests, translation sync, compile, and diff checks passed locally.
  • Wheel and sdist both built as 0.1.1, installed in separate clean environments, and exposed
    requirement-ledger 0.1.1; two installed Demo outputs were byte-identical.
  • The sdist contains the bilingual roadmaps and Skill walkthroughs and excludes bytecode, caches,
    and .private.json evidence.
  • Public CI run 33158962532 passed all 12 Python 3.10–3.13 × Ubuntu/macOS/Windows jobs and the
    built-wheel, built-sdist, deterministic-Demo, and targeted security smoke.
  • Final release-commit artefact hashes and the evidence-only commit CI remain publication gates.

中文摘要

v0.1.1 把产品定位明确为 Requirement Ledger AI:面向 Codex、Claude Code 与任意 Git
项目的 AI 项目/Skill 反馈闭环。本版新增完全合成、可复现的 Skill 改进案例与双语 15 天路线图,
并统一 CLI 与记录的版本来源。它没有扩大执行权限:CLI 仍不会自动修改 Skill、运行项目代码、
联网或执行 GitHub 动作。

Requirement Ledger v0.1.0

Choose a tag to compare

@adand-91 adand-91 released this 28 Aug 08:15

v0.1.0 — Installable evidence loop

Status: approved for release. Local gates and the public cross-platform release workflow passed
on 2026-08-28; this document is the release body for tag v0.1.0.

What changed

  • Requirement Ledger has grown from a transcript-retrospective Skill into an installable,
    privacy-first evidence and repair-planning pipeline for any Git project.
  • requirement-ledger doctor, scan, analyze, report, suggest, verify,
    privacy-check, and demo form the v0.1 CLI.
  • The new path accepts only an explicit repository and explicit transcript/test-log files.
  • Git collection is fixed and read-only; remotes are not inspected.
  • Private raw evidence, analysis, share reports, repair drafts, and validation results have
    separate versioned states.
  • Attribution is conservative: upstream, project-local, personal, or unknown, with
    unknown as the default when confirmation evidence is absent.
  • Share reports exclude quotes and local identifiers, then pass through an automated privacy
    check that never claims to replace human review.
  • Repair plans are always DRAFT — NOT SENT and not-applied.
  • The CLI does not run project code, install dependencies, access a network, edit a worktree,
    commit, push, create Issue/PR/Release, upload, or emit telemetry.

Compatibility

The original scripts/scan_transcript.py, retrospective report checker, translation checker,
templates, and references remain in the source distribution. Legacy scanner output is private;
--no-text does not make it safe to share.

Verified release-candidate evidence

  • All repository tests pass locally.
  • Python sources compile.
  • English/Chinese normative mirrors are in sync.
  • Wheel and sdist build; the wheel installs without runtime dependencies in a clean Python 3.12
    virtual environment.
  • The installed console command reports 0.1.0.
  • Two installed synthetic demo runs are byte-identical.
  • The sdist contains the Skill, bilingual core docs, references, templates, scripts, examples,
    tests, architecture, threat model, maintenance policy, release checklist, context, and handoff.
  • An explicit-input smoke run on the project leaves its Git status byte-for-byte unchanged.
  • The privacy canary returns a blocking status without printing matched values.
  • Public CI run 33154151812 passes Python 3.10–3.13 on Ubuntu, macOS, and Windows, plus the
    built-wheel, built-sdist, deterministic-demo, and targeted fail-closed security smoke.

中文摘要

Requirement Ledger v0.1.0 是一个适用于任意 Git 项目的本地、离线、隐私优先证据闭环工具。
它只读取用户明确指定的项目、对话和测试日志,生成私有证据、保守归因、无原话报告、未应用修复
草案,以及外部同一 oracle 的前后验证记录。CLI 不自动运行项目代码、不修改工作树、不联网,
也不自动创建 Issue、PR 或 Release。当前版本以英语为权威主版,并提供同步中文核心文档。

Known limitations

  • v0.1 produces candidates and plans; it does not safely execute or apply repairs.
  • Test-log parsing is a conservative text adapter, not yet structured by test framework.
  • Clean-room reproduction and authorised personal-configuration comparison are not automated,
    so most scopes remain unknown until a human supplies the missing evidence.
  • Pattern-based privacy detection has false positives and false negatives.
  • Provider formats may drift; only synthetic fixtures are shipped.
  • Daily/weekly reporting, adoption records, isolation, object-bound approvals, transactional
    apply, rollback, signed artefacts, and provenance remain future work.

The complete list stays visible in docs/PROJECT_GAPS.md.