The step_register_skills_table step called add_skill in a loop but only
committed once at the end. Because SkillRepository.create() obtains a
new session per call and only flushes (never commits), the intermediate
sessions could be garbage-collected before the final commit, rolling
back their transactions on the shared SQLite :memory: connection. Moving
_commit_pending inside the loop ensures each skill is durably committed
before the next session is created.
ISSUES CLOSED: #418
Add extended CLI flags and output rendering for plan and action
commands in the v3 plan lifecycle.
Plan use command:
- --automation-profile flag validates against BUILTIN_PROFILES and
persists to plan metadata with PLAN provenance
- --invariant flag (repeatable) passes PlanInvariant objects with
InvariantSource.PLAN to PlanLifecycleService.use_action()
- --strategy-actor, --execution-actor, --estimation-actor, and
--invariant-actor flags validate namespace/name format via
validate_namespaced_actor() before setting on the plan
Plan status/list output:
- Profile and Invariants columns added to plan status summary table
- Profile and Invariants columns added to lifecycle-list table
- _plan_spec_dict includes estimation_actor, invariant_actor, and
invariants fields in all output formats (json, yaml, plain, table)
- _print_lifecycle_plan rich panel displays invariants with source
provenance tags
Action show output:
- _print_action displays estimation_actor, invariant_actor,
invariants list, inputs_schema, and automation_profile when present
- _action_spec_dict conditionally includes estimation_actor,
invariant_actor, and inputs_schema fields
Documentation:
- docs/reference/plan_cli.md documents all extended flags, actor
override validation, and usage examples
- docs/reference/action_cli.md documents extended output fields and
YAML configuration options
Tests:
- 29 Behave scenarios in features/cli_extensions.feature covering
automation profile, invariant flags, actor override validation,
plan status/list rendering, and action show extended fields
- 5 Robot Framework integration tests in robot/cli_extensions.robot
for plan use with invariants, profiles, and actor validation
- 6 ASV benchmark suites in benchmarks/cli_extensions_bench.py
measuring parsing overhead for all new flags and rendering paths
ISSUES CLOSED: #325
Added decision_model, resource_handlers, and resources to the manually-authored
reference page nav entries in gen_ref_pages.py so mkdocs no longer warns about
pages existing in docs/reference/ but not included in the nav.
Refs: #408
Refined the branch/tag (Ref) field requirement: development issues (features,
fixes, chores) must set it to the same branch as the one in the Metadata
section once the issue reaches State/In Progress, and must always reference a
branch not a tag. Non-development issues (bug reports, questions, support)
may leave it blank or optionally point to the branch or tag being referenced.
Refs: #408
Added requirement that every issue must have its Forgejo branch/tag (Ref) field
set to the working branch once work begins. This field is separate from the
branch name in the issue body Metadata section but must match it. Setting the
field allows Forgejo to associate issues with branches in its UI.
Refs: #408
Added explicit requirement that every PR must include a detailed description
with a summary, closing keywords for linked issues, and a Forgejo dependency
link. Updated the merge checklist with PR description and dependency link
verification items. Reworked PR Process item 1 to be comprehensive about
both the description body and the issue linkage.
Refs: #408
Added milestone requirements: issues beyond State/Unverified must be assigned
to a milestone; PRs must be assigned to the same milestone as their linked
issues. Added PR label rules: every PR must carry exactly one Type/ label
matching the nature of the change. Updated the triaging checklist to include
milestone assignment and updated the merge checklist with milestone and label
verification items.
Refs: #408
Added an Unreleased section to CHANGELOG.md describing all documentation
changes in this branch: CONTRIBUTING.md expansion, implementation plan
migration to docs/timeline.md and docs/implementation-notes.md, and
removal of the monolithic implementation_plan.md.
Refs: #408
Reverts the StaticPool fix (68bc068) as it is no longer needed on
develop-hamza-2. Restores the original SingletonThreadPool default
for sqlite:///:memory: engine creation.
The default SingletonThreadPool for sqlite:///:memory: can
non-deterministically lose flushed data when multiple sessions are
created without closing (as in the bulk-register table step).
Under CI with coverage --parallel-mode and behave-parallel --processes 32,
this caused list_all() to return 2 skills instead of 3.
StaticPool guarantees all sessions share the exact same DBAPI connection,
which is the SQLAlchemy-recommended pattern for :memory: test databases.
- extract BaseResourceHandler to eliminate ~90% duplication between
GitCheckoutHandler and FsDirectoryHandler
- raise RuntimeError when sandbox.context is None instead of silent
empty string fallback
- add threading.Lock to resolver handler cache for thread safety
- type resource_lookup/type_lookup as Callable instead of Any
- log original HandlerResolutionError at DEBUG before fallback
- use behave.runner.Context in step definitions per repo convention
- add with_superseded_by() helper for frozen model mutation
- document frozen model + superseded_by interaction in docstring
- clarify sequence_number uniqueness is a persistence concern
- add scenario for invalid corrects_decision_id ULID validation
- add scenario for with_superseded_by copy behavior
- type step helper dict as dict[str, Any]
- Replace NamedTemporaryFile with mkstemp to avoid leaking an open fd
- Increase subprocess timeout from 30s to 60s for CI headroom
- Retry once on empty-output failure (signal-killed by OOM/CPU starvation)
- Include return code in failure message for easier diagnosis
freemo
hamza.khyari
khyari hamza
brent.edwards