Discussion on PTGEN spec 0.0.3

[cobycloud]

Purpose

Discuss the current specification below, for the purpose of determining how best to revise for Spec v0.0.4:

https://github.com/swarmauri/swarmauri-sdk/blob/mono/dev/pkgs/standards/ptree_dag/docs/PTGEN_SPECIFICATION_0.0.3.md#41-projects_payloadyaml

[cobycloud]

Should we add more clarity about the different CTXs, how they are derived, what phases in the generation workflow uses them, and what the best practices are for using the CTXs on the agent_default.j2 and *.j2 file templates?

[cobycloud]

Contexts

PROJ - Derived from the projects_payload.yaml, includes all packages and modules.

PKG - Derived from projects_payload.yaml, includes only the package in present scope

MOD - same deal

FILE - derived from the ptree.yaml.j2, this context is only available during rendering of a file.

Context Scope

In general, the agent prompt template and a .j2 template has access to any of these contexts, though project level files may not need a pkg/mod scope and a pkg-level file may not be a mod scope.

With PROJ, we can see everything in the project scope.

With pkg, we can see everything within our pkg-specific scope, so in the case of project-level files, they won't have a pkg-level scope, they'd just be aware of... all pkgs.

point

These contexts gives us quick ways on the agent_default and.j2 to access variables from different places.

So if we want to use the MOD's requirement, we could use that or we could use the FILE specific requirement, whatever makes sense for the given template.

Thoughts on Required vs Optional ( what does it mean to be an extras)

I'm working to make the specification clearer about what should go where, what's required, and why.

Required Context

In my opinion, if we need a key-name in a context to make the code run, then... it's required.

Such as.... project_name, project_root, template_set, template_set_override, agent_prompt_template, packages, modules, names.

EXTRAS

Anything that's not required to make the engine run, but may be required by the template_set itself.
So that may mean to the extent that everything, including purpose, description, requirements, examples, dependencies - all would fall into extras bin.
My thought is that this is the best way to communicate to template developers what the standard is, while still enabling flexibility and extendibility.

So we basically say, "hey this is everything that needs to exist in a template for it to run at all, any extras are on you as the template developer to decide" and for our own implementations, we'll leverage those extras: ie: purpose, description, requirements, examples, dependencies