Discussion on PTGEN spec 0.0.5

[cobycloud]

For the purpose of discussing and revising Spec 0.0.4

https://github.com/swarmauri/swarmauri-sdk/blob/6076cc9e81189f951cafcd7b587c0ac33366b6dc/pkgs/standards/ptree_dag/docs/specification/PTGEN_SPECIFICATION_0.0.4.md

[cobycloud]

PTGENS should support the ability to revise files based on system or user inputs. After a file set is generated, a projects_payload.yaml can be leveraged again to assess the transitive dependencies for a given file name or sort idx, and a new agent_template could be used for revision-specific requests, however currently the specification would require that we add our system or user inputs (such as pytest results) to the projects_payload.yaml or update a context directly by way of implementation.

[cobycloud]

If a change must be made to attributes on a projects_payload.yaml, such as required or extras attributes, then I propose that change should be made to the projects_payload.yaml to better align a result to outputs.

If a change must be made to a generated file to revise the generated content, then I propose this change should NOT be made to the projects_payload.yaml, rather I propose we support a run-time context that can be leveraged alongside a revision-based agent prompt template, such as agent_revision.j2.

[cobycloud]

Currently, in our implementation, the ptree.yaml.j2 renders the AGENT_PROMPT_TEMPLATE value for the FILE_CTX. It should be default to a value or optionally set at the PKG_CTX or MOD_CTX level. It's up to the template_set.

Based on the spec for workflow generation, the FILE_CTX is what's used to make final determination of the template_set.

[cobycloud]

If our implementation had to conform to Spec 0.0.4 while seeking to incorporate revision-based features, then we would have to override the FILE_CTX's AGENT_PROMPT_TEMPLATE prior file rendering.

For us, this seems fine. From an implementation standpoint, we can maintain a GLOBAL_CTX or RUNTIME_CTX that we use to override the FILE_CTX.

It adds a non-standard step in regards to the gen workflow, but perhaps without making us non-conforming.

[cobycloud]

We could update the spec in Spec 0.0.5 to discuss this case and better standardize, while still preserving a system-agnostic specification, or perhaps we can add a note that addresses this case or the case of CTX overrides or runtime CTX injections.