Prepare Scriptorium v0.15.0 release notes

Update ConfigKit and PromptKit patch versions
Clarify interface guidance and completed plan status
2026-09-28 03:01:09 +00:00 · 2026-09-28 02:41:03 +00:00 · 2026-09-28 02:25:45 +00:00 · 2026-09-28 01:47:05 +00:00 · 2026-09-28 01:44:38 +00:00 · 2026-09-28 01:43:29 +00:00
32 changed files with 1974 additions and 1070 deletions
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,4 +1,6 @@
-Please review `docs/development.md` for initial orientation in this repository and follow its task-specific reading guide.
+Start with `docs/development.md` for orientation and use its policy reading guide
 to select the policies applicable to the task. Do not read the entire suite by
 default.
-Review and follow `docs/policy/agents.md` before recommending, planning, or
+Read and follow `docs/policy/agents.md` before recommending, planning, or
-implementing changes to this repository.
+implementing repository changes.
--- a/23
+++ b/23
@@ -0,0 +1,23 @@
 Scriptorium
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: GPL-3.0-or-later
 Scriptorium is free software: you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.
 The GNU General Public License version 3 is provided in LICENSE.
 Scriptorium is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU General Public License for more details.
 Third-party code and assets are subject to their respective license terms.
 Policy documents adapted from Standard Repository Policies remain licensed
 under CC-BY-SA-4.0. See docs/oss/attribution.md for the affected material,
 upstream credit, and license links.
--- a/675
+++ b/675
@@ -1,11 +1,674 @@
-Copyright (c) 2026 Eric Rakestraw. 
+                    GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007
-Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
-1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+                            Preamble
-2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+  The GNU General Public License is a free, copyleft license for
 software and other kinds of works.
-3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+  The licenses for most software and other practical works are designed
 to take away your freedom to share and change the works.  By contrast,
 the GNU General Public License is intended to guarantee your freedom to
 share and change all versions of a program--to make sure it remains free
 software for all its users.  We, the Free Software Foundation, use the
 GNU General Public License for most of our software; it applies also to
 any other work released this way by its authors.  You can apply it to
 your programs, too.
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+  When we speak of free software, we are referring to freedom, not
 price.  Our General Public Licenses are designed to make sure that you
 have the freedom to distribute copies of free software (and charge for
 them if you wish), that you receive source code or can get it if you
 want it, that you can change the software or use pieces of it in new
 free programs, and that you know you can do these things.
  To protect your rights, we need to prevent others from denying you
 these rights or asking you to surrender the rights.  Therefore, you have
 certain responsibilities if you distribute copies of the software, or if
 you modify it: responsibilities to respect the freedom of others.
  For example, if you distribute copies of such a program, whether
 gratis or for a fee, you must pass on to the recipients the same
 freedoms that you received.  You must make sure that they, too, receive
 or can get the source code.  And you must show them these terms so they
 know their rights.
  Developers that use the GNU GPL protect your rights with two steps:
 (1) assert copyright on the software, and (2) offer you this License
 giving you legal permission to copy, distribute and/or modify it.
  For the developers' and authors' protection, the GPL clearly explains
 that there is no warranty for this free software.  For both users' and
 authors' sake, the GPL requires that modified versions be marked as
 changed, so that their problems will not be attributed erroneously to
 authors of previous versions.
  Some devices are designed to deny users access to install or run
 modified versions of the software inside them, although the manufacturer
 can do so.  This is fundamentally incompatible with the aim of
 protecting users' freedom to change the software.  The systematic
 pattern of such abuse occurs in the area of products for individuals to
 use, which is precisely where it is most unacceptable.  Therefore, we
 have designed this version of the GPL to prohibit the practice for those
 products.  If such problems arise substantially in other domains, we
 stand ready to extend this provision to those domains in future versions
 of the GPL, as needed to protect the freedom of users.
  Finally, every program is threatened constantly by software patents.
 States should not allow patents to restrict development and use of
 software on general-purpose computers, but in those that do, we wish to
 avoid the special danger that patents applied to a free program could
 make it effectively proprietary.  To prevent this, the GPL assures that
 patents cannot be used to render the program non-free.
  The precise terms and conditions for copying, distribution and
 modification follow.
                       TERMS AND CONDITIONS
  0. Definitions.
  "This License" refers to version 3 of the GNU General Public License.
  "Copyright" also means copyright-like laws that apply to other kinds of
 works, such as semiconductor masks.
  "The Program" refers to any copyrightable work licensed under this
 License.  Each licensee is addressed as "you".  "Licensees" and
 "recipients" may be individuals or organizations.
  To "modify" a work means to copy from or adapt all or part of the work
 in a fashion requiring copyright permission, other than the making of an
 exact copy.  The resulting work is called a "modified version" of the
 earlier work or a work "based on" the earlier work.
  A "covered work" means either the unmodified Program or a work based
 on the Program.
  To "propagate" a work means to do anything with it that, without
 permission, would make you directly or secondarily liable for
 infringement under applicable copyright law, except executing it on a
 computer or modifying a private copy.  Propagation includes copying,
 distribution (with or without modification), making available to the
 public, and in some countries other activities as well.
  To "convey" a work means any kind of propagation that enables other
 parties to make or receive copies.  Mere interaction with a user through
 a computer network, with no transfer of a copy, is not conveying.
  An interactive user interface displays "Appropriate Legal Notices"
 to the extent that it includes a convenient and prominently visible
 feature that (1) displays an appropriate copyright notice, and (2)
 tells the user that there is no warranty for the work (except to the
 extent that warranties are provided), that licensees may convey the
 work under this License, and how to view a copy of this License.  If
 the interface presents a list of user commands or options, such as a
 menu, a prominent item in the list meets this criterion.
  1. Source Code.
  The "source code" for a work means the preferred form of the work
 for making modifications to it.  "Object code" means any non-source
 form of a work.
  A "Standard Interface" means an interface that either is an official
 standard defined by a recognized standards body, or, in the case of
 interfaces specified for a particular programming language, one that
 is widely used among developers working in that language.
  The "System Libraries" of an executable work include anything, other
 than the work as a whole, that (a) is included in the normal form of
 packaging a Major Component, but which is not part of that Major
 Component, and (b) serves only to enable use of the work with that
 Major Component, or to implement a Standard Interface for which an
 implementation is available to the public in source code form.  A
 "Major Component", in this context, means a major essential component
 (kernel, window system, and so on) of the specific operating system
 (if any) on which the executable work runs, or a compiler used to
 produce the work, or an object code interpreter used to run it.
  The "Corresponding Source" for a work in object code form means all
 the source code needed to generate, install, and (for an executable
 work) run the object code and to modify the work, including scripts to
 control those activities.  However, it does not include the work's
 System Libraries, or general-purpose tools or generally available free
 programs which are used unmodified in performing those activities but
 which are not part of the work.  For example, Corresponding Source
 includes interface definition files associated with source files for
 the work, and the source code for shared libraries and dynamically
 linked subprograms that the work is specifically designed to require,
 such as by intimate data communication or control flow between those
 subprograms and other parts of the work.
  The Corresponding Source need not include anything that users
 can regenerate automatically from other parts of the Corresponding
 Source.
  The Corresponding Source for a work in source code form is that
 same work.
  2. Basic Permissions.
  All rights granted under this License are granted for the term of
 copyright on the Program, and are irrevocable provided the stated
 conditions are met.  This License explicitly affirms your unlimited
 permission to run the unmodified Program.  The output from running a
 covered work is covered by this License only if the output, given its
 content, constitutes a covered work.  This License acknowledges your
 rights of fair use or other equivalent, as provided by copyright law.
  You may make, run and propagate covered works that you do not
 convey, without conditions so long as your license otherwise remains
 in force.  You may convey covered works to others for the sole purpose
 of having them make modifications exclusively for you, or provide you
 with facilities for running those works, provided that you comply with
 the terms of this License in conveying all material for which you do
 not control copyright.  Those thus making or running the covered works
 for you must do so exclusively on your behalf, under your direction
 and control, on terms that prohibit them from making any copies of
 your copyrighted material outside their relationship with you.
  Conveying under any other circumstances is permitted solely under
 the conditions stated below.  Sublicensing is not allowed; section 10
 makes it unnecessary.
  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
  No covered work shall be deemed part of an effective technological
 measure under any applicable law fulfilling obligations under article
 11 of the WIPO copyright treaty adopted on 20 December 1996, or
 similar laws prohibiting or restricting circumvention of such
 measures.
  When you convey a covered work, you waive any legal power to forbid
 circumvention of technological measures to the extent such circumvention
 is effected by exercising rights under this License with respect to
 the covered work, and you disclaim any intention to limit operation or
 modification of the work as a means of enforcing, against the work's
 users, your or third parties' legal rights to forbid circumvention of
 technological measures.
  4. Conveying Verbatim Copies.
  You may convey verbatim copies of the Program's source code as you
 receive it, in any medium, provided that you conspicuously and
 appropriately publish on each copy an appropriate copyright notice;
 keep intact all notices stating that this License and any
 non-permissive terms added in accord with section 7 apply to the code;
 keep intact all notices of the absence of any warranty; and give all
 recipients a copy of this License along with the Program.
  You may charge any price or no price for each copy that you convey,
 and you may offer support or warranty protection for a fee.
  5. Conveying Modified Source Versions.
  You may convey a work based on the Program, or the modifications to
 produce it from the Program, in the form of source code under the
 terms of section 4, provided that you also meet all of these conditions:
    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.
    b) The work must carry prominent notices stating that it is
    released under this License and any conditions added under section
    7.  This requirement modifies the requirement in section 4 to
    "keep intact all notices".
    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.
    d) If the work has interactive user interfaces, each must display
    Appropriate Legal Notices; however, if the Program has interactive
    interfaces that do not display Appropriate Legal Notices, your
    work need not make them do so.
  A compilation of a covered work with other separate and independent
 works, which are not by their nature extensions of the covered work,
 and which are not combined with it such as to form a larger program,
 in or on a volume of a storage or distribution medium, is called an
 "aggregate" if the compilation and its resulting copyright are not
 used to limit the access or legal rights of the compilation's users
 beyond what the individual works permit.  Inclusion of a covered work
 in an aggregate does not cause this License to apply to the other
 parts of the aggregate.
  6. Conveying Non-Source Forms.
  You may convey a covered work in object code form under the terms
 of sections 4 and 5, provided that you also convey the
 machine-readable Corresponding Source under the terms of this License,
 in one of these ways:
    a) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by the
    Corresponding Source fixed on a durable physical medium
    customarily used for software interchange.
    b) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by a
    written offer, valid for at least three years and valid for as
    long as you offer spare parts or customer support for that product
    model, to give anyone who possesses the object code either (1) a
    copy of the Corresponding Source for all the software in the
    product that is covered by this License, on a durable physical
    medium customarily used for software interchange, for a price no
    more than your reasonable cost of physically performing this
    conveying of source, or (2) access to copy the
    Corresponding Source from a network server at no charge.
    c) Convey individual copies of the object code with a copy of the
    written offer to provide the Corresponding Source.  This
    alternative is allowed only occasionally and noncommercially, and
    only if you received the object code with such an offer, in accord
    with subsection 6b.
    d) Convey the object code by offering access from a designated
    place (gratis or for a charge), and offer equivalent access to the
    Corresponding Source in the same way through the same place at no
    further charge.  You need not require recipients to copy the
    Corresponding Source along with the object code.  If the place to
    copy the object code is a network server, the Corresponding Source
    may be on a different server (operated by you or a third party)
    that supports equivalent copying facilities, provided you maintain
    clear directions next to the object code saying where to find the
    Corresponding Source.  Regardless of what server hosts the
    Corresponding Source, you remain obligated to ensure that it is
    available for as long as needed to satisfy these requirements.
    e) Convey the object code using peer-to-peer transmission, provided
    you inform other peers where the object code and Corresponding
    Source of the work are being offered to the general public at no
    charge under subsection 6d.
  A separable portion of the object code, whose source code is excluded
 from the Corresponding Source as a System Library, need not be
 included in conveying the object code work.
  A "User Product" is either (1) a "consumer product", which means any
 tangible personal property which is normally used for personal, family,
 or household purposes, or (2) anything designed or sold for incorporation
 into a dwelling.  In determining whether a product is a consumer product,
 doubtful cases shall be resolved in favor of coverage.  For a particular
 product received by a particular user, "normally used" refers to a
 typical or common use of that class of product, regardless of the status
 of the particular user or of the way in which the particular user
 actually uses, or expects or is expected to use, the product.  A product
 is a consumer product regardless of whether the product has substantial
 commercial, industrial or non-consumer uses, unless such uses represent
 the only significant mode of use of the product.
  "Installation Information" for a User Product means any methods,
 procedures, authorization keys, or other information required to install
 and execute modified versions of a covered work in that User Product from
 a modified version of its Corresponding Source.  The information must
 suffice to ensure that the continued functioning of the modified object
 code is in no case prevented or interfered with solely because
 modification has been made.
  If you convey an object code work under this section in, or with, or
 specifically for use in, a User Product, and the conveying occurs as
 part of a transaction in which the right of possession and use of the
 User Product is transferred to the recipient in perpetuity or for a
 fixed term (regardless of how the transaction is characterized), the
 Corresponding Source conveyed under this section must be accompanied
 by the Installation Information.  But this requirement does not apply
 if neither you nor any third party retains the ability to install
 modified object code on the User Product (for example, the work has
 been installed in ROM).
  The requirement to provide Installation Information does not include a
 requirement to continue to provide support service, warranty, or updates
 for a work that has been modified or installed by the recipient, or for
 the User Product in which it has been modified or installed.  Access to a
 network may be denied when the modification itself materially and
 adversely affects the operation of the network or violates the rules and
 protocols for communication across the network.
  Corresponding Source conveyed, and Installation Information provided,
 in accord with this section must be in a format that is publicly
 documented (and with an implementation available to the public in
 source code form), and must require no special password or key for
 unpacking, reading or copying.
  7. Additional Terms.
  "Additional permissions" are terms that supplement the terms of this
 License by making exceptions from one or more of its conditions.
 Additional permissions that are applicable to the entire Program shall
 be treated as though they were included in this License, to the extent
 that they are valid under applicable law.  If additional permissions
 apply only to part of the Program, that part may be used separately
 under those permissions, but the entire Program remains governed by
 this License without regard to the additional permissions.
  When you convey a copy of a covered work, you may at your option
 remove any additional permissions from that copy, or from any part of
 it.  (Additional permissions may be written to require their own
 removal in certain cases when you modify the work.)  You may place
 additional permissions on material, added by you to a covered work,
 for which you have or can give appropriate copyright permission.
  Notwithstanding any other provision of this License, for material you
 add to a covered work, you may (if authorized by the copyright holders of
 that material) supplement the terms of this License with terms:
    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or
    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or
    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or
    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or
    e) Declining to grant rights under trademark law for use of some
    trade names, trademarks, or service marks; or
    f) Requiring indemnification of licensors and authors of that
    material by anyone who conveys the material (or modified versions of
    it) with contractual assumptions of liability to the recipient, for
    any liability that these contractual assumptions directly impose on
    those licensors and authors.
  All other non-permissive additional terms are considered "further
 restrictions" within the meaning of section 10.  If the Program as you
 received it, or any part of it, contains a notice stating that it is
 governed by this License along with a term that is a further
 restriction, you may remove that term.  If a license document contains
 a further restriction but permits relicensing or conveying under this
 License, you may add to a covered work material governed by the terms
 of that license document, provided that the further restriction does
 not survive such relicensing or conveying.
  If you add terms to a covered work in accord with this section, you
 must place, in the relevant source files, a statement of the
 additional terms that apply to those files, or a notice indicating
 where to find the applicable terms.
  Additional terms, permissive or non-permissive, may be stated in the
 form of a separately written license, or stated as exceptions;
 the above requirements apply either way.
  8. Termination.
  You may not propagate or modify a covered work except as expressly
 provided under this License.  Any attempt otherwise to propagate or
 modify it is void, and will automatically terminate your rights under
 this License (including any patent licenses granted under the third
 paragraph of section 11).
  However, if you cease all violation of this License, then your
 license from a particular copyright holder is reinstated (a)
 provisionally, unless and until the copyright holder explicitly and
 finally terminates your license, and (b) permanently, if the copyright
 holder fails to notify you of the violation by some reasonable means
 prior to 60 days after the cessation.
  Moreover, your license from a particular copyright holder is
 reinstated permanently if the copyright holder notifies you of the
 violation by some reasonable means, this is the first time you have
 received notice of violation of this License (for any work) from that
 copyright holder, and you cure the violation prior to 30 days after
 your receipt of the notice.
  Termination of your rights under this section does not terminate the
 licenses of parties who have received copies or rights from you under
 this License.  If your rights have been terminated and not permanently
 reinstated, you do not qualify to receive new licenses for the same
 material under section 10.
  9. Acceptance Not Required for Having Copies.
  You are not required to accept this License in order to receive or
 run a copy of the Program.  Ancillary propagation of a covered work
 occurring solely as a consequence of using peer-to-peer transmission
 to receive a copy likewise does not require acceptance.  However,
 nothing other than this License grants you permission to propagate or
 modify any covered work.  These actions infringe copyright if you do
 not accept this License.  Therefore, by modifying or propagating a
 covered work, you indicate your acceptance of this License to do so.
  10. Automatic Licensing of Downstream Recipients.
  Each time you convey a covered work, the recipient automatically
 receives a license from the original licensors, to run, modify and
 propagate that work, subject to this License.  You are not responsible
 for enforcing compliance by third parties with this License.
  An "entity transaction" is a transaction transferring control of an
 organization, or substantially all assets of one, or subdividing an
 organization, or merging organizations.  If propagation of a covered
 work results from an entity transaction, each party to that
 transaction who receives a copy of the work also receives whatever
 licenses to the work the party's predecessor in interest had or could
 give under the previous paragraph, plus a right to possession of the
 Corresponding Source of the work from the predecessor in interest, if
 the predecessor has it or can get it with reasonable efforts.
  You may not impose any further restrictions on the exercise of the
 rights granted or affirmed under this License.  For example, you may
 not impose a license fee, royalty, or other charge for exercise of
 rights granted under this License, and you may not initiate litigation
 (including a cross-claim or counterclaim in a lawsuit) alleging that
 any patent claim is infringed by making, using, selling, offering for
 sale, or importing the Program or any portion of it.
  11. Patents.
  A "contributor" is a copyright holder who authorizes use under this
 License of the Program or a work on which the Program is based.  The
 work thus licensed is called the contributor's "contributor version".
  A contributor's "essential patent claims" are all patent claims
 owned or controlled by the contributor, whether already acquired or
 hereafter acquired, that would be infringed by some manner, permitted
 by this License, of making, using, or selling its contributor version,
 but do not include claims that would be infringed only as a
 consequence of further modification of the contributor version.  For
 purposes of this definition, "control" includes the right to grant
 patent sublicenses in a manner consistent with the requirements of
 this License.
  Each contributor grants you a non-exclusive, worldwide, royalty-free
 patent license under the contributor's essential patent claims, to
 make, use, sell, offer for sale, import and otherwise run, modify and
 propagate the contents of its contributor version.
  In the following three paragraphs, a "patent license" is any express
 agreement or commitment, however denominated, not to enforce a patent
 (such as an express permission to practice a patent or covenant not to
 sue for patent infringement).  To "grant" such a patent license to a
 party means to make such an agreement or commitment not to enforce a
 patent against the party.
  If you convey a covered work, knowingly relying on a patent license,
 and the Corresponding Source of the work is not available for anyone
 to copy, free of charge and under the terms of this License, through a
 publicly available network server or other readily accessible means,
 then you must either (1) cause the Corresponding Source to be so
 available, or (2) arrange to deprive yourself of the benefit of the
 patent license for this particular work, or (3) arrange, in a manner
 consistent with the requirements of this License, to extend the patent
 license to downstream recipients.  "Knowingly relying" means you have
 actual knowledge that, but for the patent license, your conveying the
 covered work in a country, or your recipient's use of the covered work
 in a country, would infringe one or more identifiable patents in that
 country that you have reason to believe are valid.
  If, pursuant to or in connection with a single transaction or
 arrangement, you convey, or propagate by procuring conveyance of, a
 covered work, and grant a patent license to some of the parties
 receiving the covered work authorizing them to use, propagate, modify
 or convey a specific copy of the covered work, then the patent license
 you grant is automatically extended to all recipients of the covered
 work and works based on it.
  A patent license is "discriminatory" if it does not include within
 the scope of its coverage, prohibits the exercise of, or is
 conditioned on the non-exercise of one or more of the rights that are
 specifically granted under this License.  You may not convey a covered
 work if you are a party to an arrangement with a third party that is
 in the business of distributing software, under which you make payment
 to the third party based on the extent of your activity of conveying
 the work, and under which the third party grants, to any of the
 parties who would receive the covered work from you, a discriminatory
 patent license (a) in connection with copies of the covered work
 conveyed by you (or copies made from those copies), or (b) primarily
 for and in connection with specific products or compilations that
 contain the covered work, unless you entered into that arrangement,
 or that patent license was granted, prior to 28 March 2007.
  Nothing in this License shall be construed as excluding or limiting
 any implied license or other defenses to infringement that may
 otherwise be available to you under applicable patent law.
  12. No Surrender of Others' Freedom.
  If conditions are imposed on you (whether by court order, agreement or
 otherwise) that contradict the conditions of this License, they do not
 excuse you from the conditions of this License.  If you cannot convey a
 covered work so as to satisfy simultaneously your obligations under this
 License and any other pertinent obligations, then as a consequence you may
 not convey it at all.  For example, if you agree to terms that obligate you
 to collect a royalty for further conveying from those to whom you convey
 the Program, the only way you could satisfy both those terms and this
 License would be to refrain entirely from conveying the Program.
  13. Use with the GNU Affero General Public License.
  Notwithstanding any other provision of this License, you have
 permission to link or combine any covered work with a work licensed
 under version 3 of the GNU Affero General Public License into a single
 combined work, and to convey the resulting work.  The terms of this
 License will continue to apply to the part which is the covered work,
 but the special requirements of the GNU Affero General Public License,
 section 13, concerning interaction through a network will apply to the
 combination as such.
  14. Revised Versions of this License.
  The Free Software Foundation may publish revised and/or new versions of
 the GNU General Public License from time to time.  Such new versions will
 be similar in spirit to the present version, but may differ in detail to
 address new problems or concerns.
  Each version is given a distinguishing version number.  If the
 Program specifies that a certain numbered version of the GNU General
 Public License "or any later version" applies to it, you have the
 option of following the terms and conditions either of that numbered
 version or of any later version published by the Free Software
 Foundation.  If the Program does not specify a version number of the
 GNU General Public License, you may choose any version ever published
 by the Free Software Foundation.
  If the Program specifies that a proxy can decide which future
 versions of the GNU General Public License can be used, that proxy's
 public statement of acceptance of a version permanently authorizes you
 to choose that version for the Program.
  Later license versions may give you additional or different
 permissions.  However, no additional obligations are imposed on any
 author or copyright holder as a result of your choosing to follow a
 later version.
  15. Disclaimer of Warranty.
  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
 APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
 OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
 THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
 IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
 ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
  16. Limitation of Liability.
  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
 THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
 GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
 USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
 EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGES.
  17. Interpretation of Sections 15 and 16.
  If the disclaimer of warranty and limitation of liability provided
 above cannot be given local legal effect according to their terms,
 reviewing courts shall apply local law that most closely approximates
 an absolute waiver of all civil liability in connection with the
 Program, unless a warranty or assumption of liability accompanies a
 copy of the Program in return for a fee.
                     END OF TERMS AND CONDITIONS
            How to Apply These Terms to Your New Programs
  If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
 free software which everyone can redistribute and change under these terms.
  To do so, attach the following notices to the program.  It is safest
 to attach them to the start of each source file to most effectively
 state the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.
    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.
 Also add information on how to contact you by electronic and paper mail.
  If the program does terminal interaction, make it output a short
 notice like this when it starts in an interactive mode:
    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.
 The hypothetical commands `show w' and `show c' should show the appropriate
 parts of the General Public License.  Of course, your program's commands
 might be different; for a GUI interface, you would use an "about box".
  You should also get your employer (if you work as a programmer) or school,
 if any, to sign a "copyright disclaimer" for the program, if necessary.
 For more information on this, and how to apply and follow the GNU GPL, see
 <https://www.gnu.org/licenses/>.
  The GNU General Public License does not permit incorporating your program
 into proprietary programs.  If your program is a subroutine library, you
 may consider it more useful to permit linking proprietary applications with
 the library.  If this is what you want to do, use the GNU Lesser General
 Public License instead of this License.  But first, please read
 <https://www.gnu.org/licenses/why-not-lgpl.html>.
--- a/README.md
+++ b/README.md
@@ -6,7 +6,7 @@ OpenAI-compatible model endpoints, and returns generated output with validation
 metadata.
 The application uses
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/)
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/)
 for prompt, profile, schema, preparation, generation, and validation behavior.
 Scriptorium owns executable configuration, CLI and HTTP mapping, process
 behavior, output presentation, and HTTP artifact-containment policy.
@@ -39,8 +39,8 @@ a model. For complete invocation and output behavior, see the
 - [Migration from the former Go package](docs/consumers/migrating-to-promptkit.md)
 - [Subprocess integration](docs/integrations/subprocess.md)
 - [Architecture policy](docs/policy/architecture.md)
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
+- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
 ## Examples
@@ -52,6 +52,6 @@ a model. For complete invocation and output behavior, see the
 - [Render script](examples/render-markdown-summary.sh)
 - [HTTP request](examples/http-run.json)
-Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
+Scriptorium is licensed under the [GPL v3.0 or later](COPYRIGHT).
 [Open Source attribution notices](docs/oss/attribution.md) are available.
--- a/docs/api.md
+++ b/docs/api.md
@@ -68,11 +68,11 @@ The optional `model` object accepts `endpoint`, `model`, `temperature`,
 `max_tokens`, `top_p`, `timeout_seconds`, `service_tier`,
 `reasoning_effort`, `api_key_env`, and `extra_params`. Numeric ranges and
 framework credential semantics are defined by the
-[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
 Explicit zero values for the numeric fields are overrides; zero
 `timeout_seconds` disables the per-attempt generation deadline only, retaining the
 request context and configured transport cap. The timeout layers are defined in
-the [Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
+the [Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
 Each built-in transient retry gets a fresh generation timeout; the caller's
 request context remains the outer cancellation boundary.
--- a/docs/cli.md
+++ b/docs/cli.md
@@ -90,7 +90,7 @@ only; the caller context and configured transport cap remain active. CLI
 durations are converted to whole seconds by truncation toward zero, so any
 duration whose absolute value is below one second becomes an explicit
 zero-second override. The timeout layers are defined in the
-[Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
+[Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
 With the built-in client, each transient retry gets a fresh generation timeout;
 this flag does not limit the complete run.
 `--run-timeout` keeps subsecond precision and starts immediately before engine
--- a/docs/config.md
+++ b/docs/config.md
@@ -3,7 +3,7 @@
 This is the canonical reference for Scriptorium application settings. Prompt,
 profile, schema, execution-setting, built-in profile, and framework credential
 semantics are defined by the
-[Promptkit v0.11.0 format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit v0.11.2 format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
 For command syntax, see the [CLI reference](cli.md); for HTTP request shapes and
 outcomes, see the [HTTP API reference](api.md).
@@ -26,7 +26,7 @@ The maintained [minimal configuration](../examples/config.yml),
 ## Application Configuration File
-Configuration is decoded by ConfigKit v0.4.0 as strict YAML. Unknown fields,
+Configuration is decoded by ConfigKit v0.4.2 as strict YAML. Unknown fields,
 empty files, multiple YAML documents, and YAML aliases/anchors are rejected.
 An explicit empty string is a value: it clears a file-provided optional path
 or, for required `prompt_dir`, fails the command's prerequisite. A scalar
@@ -152,7 +152,7 @@ parse those framework file formats.
  contracts.
 See the
-[tagged Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
+[tagged Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
 for all of those definitions. The files under
 [`examples/prompts`](../examples/prompts/),
 [`examples/profiles`](../examples/profiles/), and
@@ -195,7 +195,7 @@ client retains its own retry behavior. The tagged integration contract owns
 eligibility and timing.
 Promptkit's
-[OpenAI-compatible integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
+[OpenAI-compatible integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
 defines outbound authentication, provider request mapping, transport limits,
 and timeout layering.
@@ -204,4 +204,4 @@ and timeout layering.
 - [CLI reference](cli.md)
 - [HTTP API reference](api.md)
 - [Operations guide](operations.md)
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
+- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
--- a/docs/consumers/api.md
+++ b/docs/consumers/api.md
@@ -14,7 +14,7 @@ and the HTTP service according to the boundary your application needs.
 Go applications that need an in-process prompt framework should import
 Promptkit directly. The tagged
-[Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+[Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
 owns that interface; Scriptorium does not provide a Go library package.
 Consumers arriving from the former Scriptorium Go API should follow the
 [migration guide](migrating-to-promptkit.md).
@@ -35,4 +35,4 @@ Scriptorium does not persist run state. A retry can produce different output
 and can incur another provider request. CLI exits belong to the
 [CLI reference](../cli.md), HTTP status behavior belongs to the
 [HTTP API reference](../api.md), and framework semantics belong to
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
--- a/docs/consumers/migrating-to-promptkit.md
+++ b/docs/consumers/migrating-to-promptkit.md
@@ -4,7 +4,7 @@
 Scriptorium `v0.11.1` at
 `gitea.maximumdirect.net/eric/scriptorium` is the final release that provides
-the former in-process Go framework. Promptkit `v0.11.0` at
+the former in-process Go framework. Promptkit `v0.11.1` at
 `gitea.maximumdirect.net/eric/promptkit` is the destination for that framework
 API. Scriptorium `v0.12.0` and later provide the CLI and HTTP application only.
@@ -19,7 +19,7 @@ Start from a clean consumer checkout and review the pending diff before
 committing it. Add the published Promptkit module:
 ```sh
-go get gitea.maximumdirect.net/eric/promptkit@v0.11.0
+go get gitea.maximumdirect.net/eric/promptkit@v0.11.1
 ```
 For an ordinary consumer that imports the former root package under its
@@ -51,14 +51,14 @@ go mod tidy
 go test ./...
 ```
-Confirm that `go.mod` selects Promptkit `v0.11.0` and that no Go file imports
+Confirm that `go.mod` selects Promptkit `v0.11.1` and that no Go file imports
 the former Scriptorium package:
 ```sh
 test "$(
  go list -m -f '{{.Path}}@{{.Version}}' \
    gitea.maximumdirect.net/eric/promptkit
-)" = 'gitea.maximumdirect.net/eric/promptkit@v0.11.0'
+)" = 'gitea.maximumdirect.net/eric/promptkit@v0.11.1'
 if git grep -n \
  'gitea.maximumdirect.net/eric/scriptorium' \
  -- '*.go'
@@ -73,20 +73,20 @@ fi
 Promptkit preserves the established engine, request, result, profile,
 source-option, model-client, artifact, validation-value, and public-error
 shapes where practical. Exact declarations and current behavior belong to the
-tagged [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+tagged [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md)
 and Go source.
 Promptkit also includes migration-relevant public contracts that were not in
 Scriptorium `v0.11.1`:
- [`WithArtifactReader`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/engine.go#L169-L174)
+- [`WithArtifactReader`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/engine.go#L169-L174)
  and the
-  [`ArtifactReader` declaration](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/types.go#L315)
+  [`ArtifactReader` declaration](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/types.go#L315)
  provide the artifact-reading extension described by the tagged
-  [extension-interface guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md#extension-interfaces).
+  [extension-interface guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md#extension-interfaces).
- [`ErrProfileRequired` and `ErrAPIKeyEnvMissing`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/engine.go#L33-L48)
+- [`ErrProfileRequired` and `ErrAPIKeyEnvMissing`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/engine.go#L33-L48)
  provide the specific identities described by the tagged
-  [error guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md#handle-errors).
+  [error guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md#handle-errors).
 Use those tagged owners for exact signatures, wrapping guarantees, and
 extension behavior.
--- a/docs/development.md
+++ b/docs/development.md
@@ -2,23 +2,39 @@
 This is the contributor entry point for Scriptorium. Scriptorium is an
 application that consumes the public
-[Promptkit v0.11.0 package](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md);
+[Promptkit v0.11.2 package](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md);
 framework implementation work belongs in Promptkit. Application configuration
-uses ConfigKit v0.4.0; keep Scriptorium's schema and source selection local.
+uses ConfigKit v0.4.2; keep Scriptorium's schema and source selection local.
 ## Initial Orientation
 Before recommending, planning, or implementing work:
-1. read the [agent policy](policy/agents.md);
+1. inspect the working tree and preserve unrelated changes;
-2. inspect the working tree and preserve unrelated changes;
+2. use the policy and task-specific reading guides below; and
-3. read the [architecture policy](policy/architecture.md);
+3. inspect the relevant implementation and tests before changing them.
 4. follow the task-specific contracts and internal documents below; and
 5. inspect the relevant implementation and tests before changing them.
-Also read the [documentation policy](policy/documentation.md) before changing
+## Policy Reading Guide
-documentation and the [testing policy](policy/testing.md) before changing
+
-tests.
+| Policy | Read before… |
 | --- | --- |
 | [Policy set provenance](policy/meta.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
 | [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
 | [Architecture](policy/architecture.md) | Planning or changing application code or its structure. |
 | [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
 | [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
 | [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
 | [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |
 - Read applicable policies before making decisions they govern; multiple policies
  may apply.
 - Select policies using the task triggers above. Follow cross-references to
  relevant sections when needed to resolve a concrete question.
 - Reuse policies already available in context; reread when changed or no longer
  available.
 - Expand reading when the task's scope expands.
 - When revising a policy itself, read that policy and any provisions elsewhere
  affected by the revision.
 ## Task-Specific Reading Guide
@@ -29,13 +45,13 @@ tests.
 | HTTP routes, DTOs, limits, status mapping, or artifact policy | [HTTP API contract](api.md), [adapter internals](internal/adapters.md), and [source internals](internal/sources.md) |
 | Application configuration or precedence | [Configuration contract](config.md), [adapter internals](internal/adapters.md), [source internals](internal/sources.md), and `internal/config` definition/load tests |
 | Prepared-run presentation | [CLI contract](cli.md), [adapter internals](internal/adapters.md), and `internal/format` |
-| Prompt, profile, schema, generation, or validation semantics | [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md) and the [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md) |
+| Prompt, profile, schema, generation, or validation semantics | [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md) and the [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md) |
-| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md) |
+| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md) |
 | Subprocess behavior | [Subprocess integration](integrations/subprocess.md) and [CLI contract](cli.md) |
 | Runtime operation or recovery | [Operations](operations.md) |
 | Dependencies, copied assets, or attribution | The [OSS policy](policy/oss.md), [component attributions](oss/attribution.md), and [architecture policy](policy/architecture.md) |
 | Release documentation, packaging, or publication | The [release policy](policy/release.md), [OSS policy](policy/oss.md), [release procedure](release.md), [hosted release workflow](../.woodpecker/release.yml), and [architecture policy](policy/architecture.md) |
-| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md), and the related files under `examples/` |
+| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md), and the related files under `examples/` |
 | Architecture decisions or future work | The [documentation policy](policy/documentation.md), relevant accepted ADRs, and relevant roadmap documents |
 Cross-project changes land and release in Promptkit before Scriptorium adopts
--- a/docs/internal/adapters.md
+++ b/docs/internal/adapters.md
@@ -9,7 +9,7 @@ own IO and presentation mechanics, not framework decisions.
 External contracts are canonical in the [CLI reference](../cli.md) and
 [HTTP API reference](../api.md). Promptkit's public engine contract is
 described by its tagged
-[Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md).
+[Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md).
 ## Components And Collaborators
--- a/docs/internal/overview.md
+++ b/docs/internal/overview.md
@@ -15,5 +15,5 @@ public behavior belongs in the linked contracts.
 | `internal/report` | Projects one terminal Promptkit observation into Scriptorium-owned execution metadata. | [adapter internals](adapters.md) |
 Framework implementation packages are provided by
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
 and are not part of this repository.
--- a/docs/internal/sources.md
+++ b/docs/internal/sources.md
@@ -5,7 +5,7 @@
 This document covers Scriptorium-owned source locations and the restricted HTTP
 artifact reader. Prompt, profile, schema, and ordinary artifact semantics are
 owned by the tagged
-[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
+[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
 ## Application Source Locations
--- a/docs/operations.md
+++ b/docs/operations.md
@@ -9,7 +9,7 @@ fields, or HTTP wire behavior.
 - [CLI reference](cli.md): commands, output destinations, and exit codes.
 - [Configuration reference](config.md): application settings, source
  locations, defaults, and credential mapping.
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md):
+- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md):
  prompt, profile, schema, execution-setting, and framework credential
  contracts.
 - [HTTP API reference](api.md): route, request/response schema, status codes,
@@ -150,7 +150,7 @@ setting and then Promptkit's default, while explicit zero disables additional
 attempts. Existing generation timeouts apply
 per attempt, while the caller context covers the complete operation. Provider
 `Retry-After` timing can exceed Promptkit's ordinary backoff cap; consult the
-[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
+[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
 for details.
 CLI `run` can set a [whole-run deadline](cli.md) when total execution time must
--- a/docs/oss/attribution.md
+++ b/docs/oss/attribution.md
@@ -1,91 +1,110 @@
-# Open-Source Attribution
+# Open Source Attribution Notices
-Scriptorium's own terms are in the repository [LICENSE](../../LICENSE).
+## Standard Repository Policies
-The [OSS policy](../policy/oss.md) governs these entries. Dependency versions
+
-are recorded in [go.mod](../../go.mod) and [go.sum](../../go.sum); source and
+Material: `docs/policy/oss.md`, `docs/policy/meta.md`,
-notice links below identify the exact commits for the selected versions.
+`docs/policy/agents.md`, `docs/policy/documentation.md`,
 `docs/policy/architecture.md`, `docs/policy/testing.md`,
 `docs/policy/release.md`, `AGENTS.md`, and the
 Policy Reading Guide section of `docs/development.md`, adapted for this
 repository.
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: CC-BY-SA-4.0
 License and notices: [CC BY-SA 4.0](licenses/CC-BY-SA-4.0.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843).
 ## Promptkit
 Selected module: `gitea.maximumdirect.net/eric/promptkit` at `v0.11.2`.
 Copyright (C) 2026 Eric Rakestraw
 SPDX-License-Identifier: LGPL-3.0-or-later
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
+License and notices: [LGPL 3.0](licenses/LGPL-3.0.txt) |
-[GPL v3 companion](licenses/GPL-3.0.txt) |
+[GPL 3.0](licenses/GPL-3.0.txt) |
-[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d/LICENSE)
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2/LICENSE).
-Source: [Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d)
+[Source](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2).
 ## ConfigKit
-Upstream copyright statement: no project-specific statement is present in the
+Selected module: `gitea.maximumdirect.net/eric/ConfigKit` at `v0.4.2`.
 selected module; the FSF copyright in its license text belongs to that license
 document and is not substituted for a project notice.
-SPDX-License-Identifier: LGPL-3.0-only
+Copyright (C) 2026 Eric Rakestraw
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
+SPDX-License-Identifier: LGPL-3.0-or-later
 [GPL v3 companion](licenses/GPL-3.0.txt) |
 [upstream LICENSE](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/e6ced0d3d1194b58e0b3dc8970089471ba175258/LICENSE)
-Source: [ConfigKit v0.4.0](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/e6ced0d3d1194b58e0b3dc8970089471ba175258)
+License and notices: [LGPL 3.0](licenses/LGPL-3.0.txt) |
 [GPL 3.0](licenses/GPL-3.0.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f).
 ## Promptkit OpenRouter Catalog
-Upstream copyright statement: no project-specific statement is present in the
+Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2` at `v2.20260926.0`.
 selected module. The linked upstream README records the profile assets'
 Promptkit origin and the copyright holder's deliberate relicensing.
-SPDX-License-Identifier: LGPL-3.0-only
+Copyright (C) 2026 Eric Rakestraw
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
+SPDX-License-Identifier: MIT
 [GPL v3 companion](licenses/GPL-3.0.txt) |
 [upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/LICENSE) |
 [asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/README.md)
-Source: [OpenRouter catalog v2.20260922.1](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab)
+License and notices: [MIT](licenses/MIT.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3).
 ## Promptkit Rakestrawhome Catalog
-Upstream copyright statement: no project-specific statement is present in the
+Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2` at `v2.20260926.0`.
 selected module. The linked upstream README records the profile asset's
 Promptkit origin and the copyright holder's deliberate relicensing.
-SPDX-License-Identifier: LGPL-3.0-only
+Copyright (C) 2026 Eric Rakestraw
-License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
+SPDX-License-Identifier: MIT
 [GPL v3 companion](licenses/GPL-3.0.txt) |
 [upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/LICENSE) |
 [asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/README.md)
-Source: [Rakestrawhome catalog v2.20260922.0](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226)
+License and notices: [MIT](licenses/MIT.txt) |
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596/COPYRIGHT) |
 [LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596/LICENSE).
 [Source](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596).
 ## jsonschema/v6
-Upstream copyright statement: no project-specific statement is present in the
+Selected module: `github.com/santhosh-tekuri/jsonschema/v6` at `v6.0.2`.
 selected module; no substitute statement is inferred here.
 SPDX-License-Identifier: Apache-2.0
 License and notices: [Apache 2.0](licenses/Apache-2.0.txt) |
-[upstream LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE)
+[LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE).
-Source: [jsonschema/v6 v6.0.2](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71)
+[Source](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71).
 ## golang.org/x/text
 Selected module: `golang.org/x/text` at `v0.14.0`.
 Copyright (c) 2009 The Go Authors. All rights reserved.
 SPDX-License-Identifier: BSD-3-Clause
 License and notices: [BSD 3-Clause](licenses/BSD-3-Clause.txt) |
-[upstream LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE)
+[LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE).
-Source: [golang.org/x/text v0.14.0](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353)
+[Source](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353).
 ## gopkg.in/yaml.v3
 Selected module: `gopkg.in/yaml.v3` at `v3.0.1`.
 Copyright (c) 2006-2010 Kirill Simonov
 Copyright (c) 2006-2011 Kirill Simonov
@@ -96,18 +115,17 @@ Copyright 2011-2016 Canonical Ltd.
 SPDX-License-Identifier: MIT AND Apache-2.0
 The upstream LICENSE assigns MIT to files ported from libyaml and Apache 2.0
 to the remaining files; these are file-specific terms, not alternatives.
 License and notices: [MIT](licenses/MIT.txt) |
 [Apache 2.0](licenses/Apache-2.0.txt) |
-[upstream LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
+[LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
-[upstream NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE)
+[NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE).
-Source: [gopkg.in/yaml.v3 v3.0.1](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51)
+[Source](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51).
 ## go.yaml.in/yaml/v4
 Selected module: `go.yaml.in/yaml/v4` at `v4.0.0-rc.6`.
 Copyright 2006-2010 Kirill Simonov
 Copyright 2011-2019 Canonical Ltd
@@ -116,12 +134,9 @@ Copyright 2025 The go-yaml Project Contributors
 SPDX-License-Identifier: MIT AND Apache-2.0
 The upstream NOTICE assigns MIT to files ported from libyaml and Apache 2.0
 to the remaining files; these are file-specific terms, not alternatives.
 License and notices: [MIT](licenses/MIT.txt) |
 [Apache 2.0](licenses/Apache-2.0.txt) |
-[upstream LICENSE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/LICENSE) |
+[LICENSE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/LICENSE) |
-[upstream NOTICE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/NOTICE)
+[NOTICE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/NOTICE).
-Source: [go.yaml.in/yaml/v4 v4.0.0-rc.6](https://github.com/yaml/go-yaml/tree/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125)
+[Source](https://github.com/yaml/go-yaml/tree/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125).
--- a/docs/oss/licenses/CC-BY-SA-4.0.txt
+++ b/docs/oss/licenses/CC-BY-SA-4.0.txt
@@ -0,0 +1,170 @@
 Creative Commons Attribution-ShareAlike 4.0 International
 Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
 Using Creative Commons Public Licenses
 Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
 Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
 Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described.
 Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.
 Creative Commons Attribution-ShareAlike 4.0 International Public License
 By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
 Section 1 – Definitions.
     a.	Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
     b.	Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
     c.	BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License.
     d.	Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
     e.	Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
     f.	Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
     g.	License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
     h.	Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
     i.	Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
     j.	Licensor means the individual(s) or entity(ies) granting rights under this Public License.
     k.	Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
     l.	Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
     m.	You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
 Section 2 – Scope.
     a.	License grant.
          1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
               A. reproduce and Share the Licensed Material, in whole or in part; and
               B. produce, reproduce, and Share Adapted Material.
          2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
          3. Term. The term of this Public License is specified in Section 6(a).
          4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
          5. Downstream recipients.
               A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
               B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
               C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
          6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
     b.	Other rights.
          1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
          2. Patent and trademark rights are not licensed under this Public License.
          3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
 Section 3 – License Conditions.
 Your exercise of the Licensed Rights is expressly made subject to the following conditions.
     a.	Attribution.
          1. If You Share the Licensed Material (including in modified form), You must:
               A. retain the following if it is supplied by the Licensor with the Licensed Material:
                    i.	identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
                    ii.	a copyright notice;
                    iii. a notice that refers to this Public License;
                    iv.	a notice that refers to the disclaimer of warranties;
                    v.	a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
               B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
               C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
          2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
          3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
     b.	ShareAlike.In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
          1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
          2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
          3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
 Section 4 – Sui Generis Database Rights.
 Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
     a.	for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
     b.	if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
     c.	You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
 For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
 Section 5 – Disclaimer of Warranties and Limitation of Liability.
     a.	Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
     b.	To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
     c.	The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
 Section 6 – Term and Termination.
     a.	This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
     b.	Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
          1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
          2. upon express reinstatement by the Licensor.
     c.	For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
     d.	For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
     e.	Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
 Section 7 – Other Terms and Conditions.
     a.	The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
     b.	Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
 Section 8 – Interpretation.
     a.	For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
     b.	To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
     c.	No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
     d.	Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
 Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
 Creative Commons may be contacted at creativecommons.org.
--- a/docs/policy/agents.md
+++ b/docs/policy/agents.md
@@ -1,12 +1,14 @@
 # Agent Policy
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md
 ## Purpose
-Agents working in this repository must read and adhere to the following house rules.
+Agents must read and follow these rules.
 ## Implementation Discipline
@@ -43,15 +45,15 @@ unless that behavior was expressly selected as part of the contract.
 ## Git Commit Policy
-By default, create a commit after completing each coherent unit of work, using a
+By default, commit each completed, nonempty unit of work using a
 concise, plain-English message describing what changed. This policy is standing
 authorization to create those local commits; a separate user request is not
 required. An explicit user instruction to leave work uncommitted takes precedence.
 A unit of work is a focused, reviewable outcome, including its relevant tests and
-documentation. Do not commit after every intermediate edit or create empty commits.
+documentation.
 Complete the appropriate validation before committing. If work is incomplete or
-validation is blocked, report that state rather than presenting it as completed.
+validation is blocked, report that state accurately.
 Before committing:
@@ -59,10 +61,10 @@ Before committing:
   changes. Identify changes that predate the current unit of work.
 2. Exclude secrets, local environment files, generated junk, and unrelated changes.
 3. Stage only the files or hunks belonging to the completed unit. Use `git add .`
-   only when every included change belongs to that unit. Do not disturb unrelated
+   only when every included change belongs to that unit. Preserve unrelated
-   staged or unstaged work.
+   staged and unstaged work.
-4. Review `git diff --staged` and run appropriate checks for the change. Do not
+4. Review `git diff --staged` and run appropriate checks for the change. Reuse
-   repeat checks already passed for unchanged content merely to create a commit.
+   successful checks for unchanged content.
 5. Review `git log --oneline -n 10` and use
   `git commit -m "<concise plain-English commit message>"`.
 6. Report the commit identifier and any remaining uncommitted work.
--- a/docs/policy/architecture.md
+++ b/docs/policy/architecture.md
@@ -1,147 +1,110 @@
 # Architecture Policy
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md
 ## Purpose And Ownership
-This policy defines Scriptorium's purpose, responsibility and dependency
+The adopted policy defines the application's purpose and the architectural
-boundaries, established invariants, and non-goals. Concrete component inventory
+constraints contributors must follow. It owns system boundaries, responsibility
-and implementation mechanics belong in [internal documentation](../internal/overview.md);
+and dependency rules, established invariants, and explicit non-goals.
 public behavior belongs in its canonical contracts.
-Adopted constraints govern future development without implying that every
+Describe the concrete package inventory and implementation mechanics in internal
-capability they could govern exists or is planned. Keep proposed structure and
+documentation. Link to canonical public contracts for their exact behavior and
-implementation status in roadmaps, and decision rationale in ADRs. Acceptance
+to ADRs for decision rationale.
 of a decision is not proof of implementation. Do not turn incidental choices
 into architectural invariants.
-## System Shape
+## Architectural Approach
-Scriptorium is an executable application with four command entry paths: CLI
+Hexagonal architecture is strongly recommended, including encapsulating external
-`run`, CLI `render`, CLI `inspect`, and the HTTP service started by `serve`.
+integrations and APIs within internal adapters. Keep domain and application
-The `inspect` command has prompt and profile modes. Scriptorium does not expose
+logic independent of external integration details, and make dependency direction
-a reusable root Go package.
+clear in the adopted policy.
-The application consumes
+Implement that separation with proportionate, idiomatic code. Choose interfaces
-[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
+and package layout to serve the application's actual boundaries. Use adapters
-through its supported root package. Promptkit owns prompt execution,
+for collaborators with external integration responsibilities.
 preparation, source formats, built-in profiles, model-client behavior, and
 validation. Scriptorium owns application configuration, executable adapters,
 prepared-run and definition-inspection presentation, process behavior, and HTTP
 deployment policy.
-Scriptorium also consumes ConfigKit v0.4.0 for application configuration
+## Adopted Constraints And Implemented Structure
 decoding, resolution, and validation flow. Scriptorium owns its application
 schema, defaults, normalization, validation rules, source selection, and CLI
 flag mapping; ConfigKit does not own Promptkit framework sources or HTTP
 artifact containment.
-The concrete package inventory is maintained in the
+Architectural constraints govern current and future development. Record
-[internal overview](../internal/overview.md).
+implemented structure accurately, proposals and implementation status in the
 roadmap, and significant decisions and rationale in ADRs. Describe a target
 structure as implemented when its changes land.
-As established by [ADR 0004](../adr/0004-definition-boundary.md), Scriptorium
+Constraints must reflect deliberately selected requirements and decisions.
-aims to support the complete set of features in valid Promptkit prompt and
+Do not promote incidental implementation choices into architectural invariants.
 profile definitions for its selected upstream version. Promptkit remains the
 canonical parser and validator. Library-only features are considered
 individually against the simple predefined-prompt execution model.
-Maintain adapter boundaries with proportionate, idiomatic code. This approach
+## Scriptorium's Purpose And System Shape
 does not require an interface for every type, additional wrappers, or a fixed
 directory tree for integrations that do not exist.
-## Dependency Direction
+Scriptorium is an executable application with CLI `run`, `render`,
 `inspect`, and `config` command families and an HTTP service started by
 `serve`. It offers simple, request-independent execution of predefined
 prompts, not a reusable Scriptorium root Go API or a workflow framework.
 The [internal overview](../internal/overview.md) owns the concrete package
 inventory; [adapter internals](../internal/adapters.md) and
 [source internals](../internal/sources.md) own implementation mechanics.
-```text
+## Framework And Application Boundaries
 cmd/scriptorium
        |
        v
 CLI and HTTP adapters, configuration, defaults, and formatting
        |
        v
 Promptkit (execution) and ConfigKit (application configuration)
 ```
- Retained application packages may import Promptkit's root package.
+Scriptorium consumes
- They must not import Promptkit `internal` packages.
+[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
- They must not import Promptkit catalog modules directly.
+through its supported public root package. Promptkit owns prompt execution,
- They must not import the removed Scriptorium root facade or recreate former
+preparation, prompt and profile formats, built-in profiles, model-client
-  framework package families.
+behavior, validation, and framework defaults. Scriptorium owns application
- Adapter-owned interfaces use Promptkit public values when a consumer-side
+configuration, executable CLI and HTTP adapters, prepared-run and
-  substitution boundary is needed.
+definition-inspection presentation, process behavior, and HTTP deployment
- Scriptorium passes omitted framework settings as zero values so Promptkit
+policy. The [format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
-  applies its own defaults.
+and [outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
 remain Promptkit's contracts.
-The repository architecture guard enforces these import and removal
+Scriptorium uses ConfigKit v0.4.2 for strict application YAML decoding,
-invariants.
+resolution, and validation flow. Scriptorium retains its application schema,
 defaults, normalization, validation rules, source selection, and CLI override
 mapping. ConfigKit does not own Promptkit framework sources or HTTP artifact
 containment. The [configuration contract](../config.md) owns externally
 observable configuration behavior.
-Cross-project changes land and release in Promptkit before Scriptorium adopts
+Application code may import Promptkit's public root package, but not its
-the tagged dependency. Do not commit Go workspaces, local replacements,
+`internal` packages or catalog modules. It must not recreate the removed
-vendored Promptkit implementation, or unpublished dependency assumptions.
+Scriptorium framework facade or former framework package families.
 Adapter-owned interfaces use Promptkit public values when a consumer-side
 substitution boundary is needed. Omitted framework settings pass as zero
 values so Promptkit applies its own defaults. Cross-project changes land and
 release in Promptkit before
 Scriptorium adopts its tagged dependency; do not commit Go workspaces, local
 replacements, vendored Promptkit source, or unpublished dependency assumptions.
 The repository's architecture guard protects these import and removal
 boundaries. Adapter separation does not require an interface for every type,
 extra wrappers, or a fixed directory tree.
-## Retained Boundaries
+## Definition Support And Request State
- `internal/adapter/cli` owns commands, flags, configuration precedence,
+As decided in [ADR 0004](../adr/0004-definition-boundary.md), Scriptorium aims
-  process streams, output files, summaries, and exit codes.
+to support the complete set of features in valid Promptkit prompt and profile
- `internal/adapter/http` owns routes, strict JSON DTOs, size limits, response
+definitions for its selected upstream version. Promptkit remains the canonical
-  mapping, status mapping, and the restricted artifact reader.
+parser and validator. Library-only features are considered individually
- `internal/config` owns discovery and Scriptorium's application definition;
+against Scriptorium's simple predefined-prompt execution model.
  ConfigKit owns strict YAML decoding and the load/override pipeline.
 - `internal/defaults` owns Scriptorium application and HTTP defaults only.
 - `internal/format` owns deterministic prepared-run and definition-inspection
  text and JSON presentation.
 - Promptkit owns framework orchestration and contracts. Its
  [format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
  and
  [outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
  are canonical.
-## HTTP Artifact Security Boundary
+External YAML and JSON decoding remains strict. Adapters map external values
-
+through Promptkit public requests and results without taking over framework
-Ordinary CLI file loading is provided by Promptkit. Scriptorium's HTTP adapter
+orchestration. Explicit numeric request overrides preserve presence, including
-injects a restricted `promptkit.ArtifactReader` for inbound HTTP requests.
+zero. Adapters map Promptkit public error identities to CLI exits or HTTP
-That reader denies file references without an artifact root, enforces the
+statuses without classifying by message text. Raw API keys are not accepted
-configured byte limit, and applies Scriptorium's lexical root-containment rule.
+in Scriptorium configuration, CLI arguments, or HTTP payloads, and resolved
 The operating system still follows symlinks after the lexical check.
 This boundary handles untrusted request references under the documented
 deployment model; it is not a filesystem sandbox. Defending against a
 privileged actor concurrently modifying the host filesystem is outside the
 adopted scope, not a claim that such activity cannot occur. Do not infer
 additional defenses or guarantees from hypothetical threats; raise unsettled
 scope decisions under the [agent policy](agents.md).
 The [HTTP API](../api.md) owns observable request outcomes, and
 [operations](../operations.md) owns deployment permissions and root selection.
 ## State, Errors, And Secrets
 Scriptorium has no durable run-state store, checkpoint, cache, or resume
 mechanism. Recovery is a new request after correcting inputs, configuration, or
 environment.
 Each request is self-contained from the caller's perspective, without
 conversation or workflow state retained from completed requests. This does
 not mean the process is internally stateless. Shared engines, backend capacity
 and queue accounting, in-flight coordination, cancellation, and server
 lifecycle resources are permitted and must be shared where necessary to
 enforce configured backend limits across concurrent requests. Such state must
 be concurrency-safe and does not create a durable user-workflow contract.
 Adapters map Promptkit public error identities into CLI exits or HTTP statuses
 without classifying by message text. Raw API keys are not accepted in
 Scriptorium configuration, CLI arguments, or HTTP payloads, and resolved
 secrets must not be emitted.
-## Architectural Invariants
+Each execution request is self-contained from the caller's perspective; no
-
+conversation or workflow state is retained from completed requests. This
- External YAML and JSON decoding remains strict.
+does not preclude process-scoped operational state. A server shares its
- CLI and HTTP behavior remains presentation and transport logic rather than
+Promptkit engine, backend registry, capacity admission and queue accounting
-  framework orchestration.
+across relevant concurrent requests so configured backend limits cannot be
- Explicit numeric request overrides preserve presence, including zero.
+bypassed by per-request construction. In-flight coordination, cancellation,
- HTTP artifact containment and byte limits remain Scriptorium policy.
+and server lifecycle state must be concurrency-safe. None of this creates a
- No application package depends on Promptkit implementation packages.
+durable workflow, checkpoint, cache, or resume contract; recovery is a new
 request after correcting inputs, configuration, or environment.
 ## Non-Goals
@@ -153,5 +116,19 @@ secrets must not be emitted.
 - Do not add durable workflow, archive, or resume behavior.
 - Do not add application-managed prompt modification, follow-up message flows,
  conversation management, or multi-step workflow orchestration.
 ## Trust Boundaries And Threat Scope
-Work that is not implemented belongs in `docs/roadmap/`.
+Ordinary CLI file loading belongs to Promptkit. For untrusted inbound HTTP
 artifact references, Scriptorium injects a restricted
 `promptkit.ArtifactReader`. It denies file references without an artifact
 root, applies the configured byte limit, and enforces lexical root containment.
 The operating system follows symlinks after that lexical check. This is not a
 filesystem sandbox or a defense against a privileged actor concurrently
 modifying the host filesystem; that threat is outside the adopted scope.
 Do not infer stronger defenses from hypothetical threats. Raise unsettled
 scope decisions under the [agent policy](agents.md).
 The [HTTP API](../api.md) owns observable request outcomes, the
 [configuration contract](../config.md) owns credential supply, and
 [operations](../operations.md) owns deployment permissions and root selection.
 The [source internals](../internal/sources.md) describe reader mechanics.
--- a/docs/policy/documentation.md
+++ b/docs/policy/documentation.md
@@ -1,15 +1,16 @@
 # Documentation Policy
-**Base Policy Version:** 1.4
+**Base Policy Version:** 1.11
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md
 ## Purpose
 This policy assigns each documentation topic to one canonical owner. Its goal is
-to keep this repository's documentation accurate, concise, discoverable, and
+to keep this application's documentation accurate, concise, discoverable, and resistant
-resistant to drift for users, operators, developers, integrators, and LLM
+to drift for users, operators, developers, integrators, and LLM coding agents.
 coding agents.
 ## Core Rules
@@ -17,45 +18,38 @@ coding agents.
 Each authoritative fact belongs in one document. A non-owning document may give
 a short, stable summary for orientation, but it must link to the canonical owner
-instead of repeating volatile details.
+for volatile details.
 Volatile details include commands, flags, configuration fields and defaults,
 module keys, schemas, file names, paths, status codes, retry behavior, and
 runtime guarantees. If readers could reasonably treat a statement as a
 contract, maintain it only in the owning document.
 Minimal tested usage examples are allowed outside the owning contract when this
 policy assigns them an orientation or instructional purpose. They must link to
 the canonical contract and must not redefine complete syntax, defaults, or
 semantics.
 ### Current And Future Behavior
 Outside `docs/roadmap/`, documentation describes implemented behavior only.
 Partial features may be described only to their implemented boundary.
-Architectural constraints may govern future changes without implying that the
+Architectural constraints may govern future changes. Describe current structure
-components or capabilities they would govern already exist. This does not
+from implemented behavior.
 permit describing a proposed system structure as implemented.
-ADRs may record an accepted architectural decision before implementation, but
+ADRs may record an accepted architectural decision before implementation. The
-acceptance must not be presented as proof that the behavior exists. The roadmap
+roadmap owns implementation status and sequencing until the decision is
-owns implementation status and sequencing until the decision is implemented.
+implemented. Current architecture, user, operator, integration, and internal
-Current architecture, user, operator,
+documentation are updated when the behavior lands.
 integration, and internal documentation are updated when the behavior lands.
 ### Audience And Detail
 Write for the document's stated audience and include only the detail needed for
-its owned topic. User and operator docs should not expose implementation detail.
+its owned topic. Keep user and operator docs focused on using and operating the
-Developer docs should link to user-facing and external contracts rather than
+application. Developer docs should link to user-facing and external contracts
-restate them.
+for their definitions.
 ### Examples
 Complete copyable files belong in `examples/`. Documentation may use the
 smallest illustrative snippet needed to explain its owned topic, but should link
-to maintained examples instead of embedding a second complete copy.
+to maintained examples for complete copyable files.
 Examples must be valid, secret-free, and tested where practical. Commands and
 configuration used in documentation should match the application.
@@ -71,43 +65,42 @@ secret values.
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward, including license and attribution navigation. | Complete command reference, configuration reference, operational procedures, implementation detail. |
+| Product orientation and minimal end-to-end quickstart | `README.md` | Purpose, value, shortest successful invocation, and navigation, including licensing and attribution. | Complete command reference, configuration reference, operational procedures, implementation detail. |
-| Contributor entry point | `docs/development.md` | Task-oriented reading guide, minimal contributor orientation, baseline validation commands, and links to canonical docs. | Package inventory, architecture rules, subsystem behavior, and detailed change recipes, which belong in the relevant internal component document. |
+| Contributor entry point | `docs/development.md` | Task-oriented reading guide, contributor orientation, baseline validation commands, and canonical links. | Package inventory, architecture rules, subsystem behavior, detailed change recipes. |
-| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, architectural boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
+| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
-| Agent policy | `docs/policy/agents.md` | Agent implementation discipline, proportionality, idiomatic simplicity, local commit rules, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
+| Policy-set provenance and upstream navigation | `docs/policy/meta.md` | Policy-set origin, local authority, adoption baselines, and upstream adoption and update links. | Task-specific reading triggers, detailed adoption procedures, and formal attribution notices. |
-| Documentation organization | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
+| Agent policy | `docs/policy/agents.md` | Proportionate, idiomatic implementation; rules against inventing requirements, restrictions, guarantees, or policy. | Application contracts, architecture, testing policy, and contributor procedures. |
-| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression-test policy, and criteria for adding, rewriting, or deleting tests. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
+| Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
 | Testing policy | `docs/policy/testing.md` | Test philosophy, risk sufficiency, boundaries, doubles, coverage, regressions, and test maintenance. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
 | Release policy | `docs/policy/release.md` | Versioning, compatibility, release integrity and immutability, release documentation, proportionate gates, publication controls, completion, and required versus optional checks. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
 | Open source licensing and attribution policy | `docs/policy/oss.md` | License defaults and author choices, COPYRIGHT and attribution formats, license/notice links, discoverability, maintenance, and concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
 | Project copyright and license grant | `COPYRIGHT` | Project identity, copyright holders and years, SPDX expression, grant, warranty disclaimer, and third-party statement. | Complete license texts and upstream component attribution. |
 | Project license texts | `LICENSE` | Complete project and incorporated companion license texts, with required project-specific fields. | General licensing policy and upstream component attribution. |
 | Upstream component attribution | `docs/oss/attribution.md` | House Format component entries: identity, material scope and modifications where applicable, copyright, license, required notices, and license, notice, and source links. | General attribution policy, exception reasoning, research narratives, compliance commentary, and complete standard license texts. |
 | Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by applicable entries. | Project-specific upstream notices, attribution prose, and policy interpretation. |
 | Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, validation and publication commands and automated guards, asynchronous deliverables, delivery status, optional consumer verification, and recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
 | CLI contract | `docs/cli.md` | Commands, arguments, flags, invocation semantics, and exit codes. | End-to-end operating procedures, configuration field definitions, runtime filesystem layout, module implementation details. |
-| Configuration contract | `docs/config.md` | Application discovery and precedence, source locations, server fields, render default, HTTP limits, and credential mapping. | Promptkit framework formats and defaults, complete example files, CLI syntax, runtime lifecycle, and implementation detail. |
+| Configuration contract | `docs/config.md` | Application configuration discovery, precedence, schema, fields, defaults, environment overrides, validation, and selectable module and validator keys. | PromptKit framework formats and defaults, complete example files, CLI syntax, runtime state lifecycle, module implementation details. |
-| Operations | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache, and debug handling, resume, cleanup, permissions, recovery, and operational limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
+| Operations | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache and debug handling, resume, cleanup, permissions, recovery, and limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
 | Release policy | `docs/policy/release.md` | Versioning and compatibility, release integrity and immutability, documentation requirements, proportionate gates, publication controls, source completion, and optional verification boundaries. | Repository-specific commands, installation guidance, historical summaries, and CI implementation details. |
 | Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, publication command and guards, asynchronous delivery, optional diagnostics, and failure recovery. | General release requirements, runtime operations, historical announcements, and current application contracts. |
 | Version-specific release notes | `docs/releases/` | Immutable release summaries, compatibility notices, and migration announcements for one published version. | Complete CLI, HTTP, configuration, operations, or dependency contracts. |
 | Open source licensing and attribution policy | `docs/policy/oss.md` | House attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
 | Project license | `LICENSE` | The project's own license terms. | Upstream component attribution and dependency license texts. |
 | Upstream component attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General attribution policy and complete standard license texts. |
 | Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by attribution entries where applicable. | Project-specific upstream notices, attribution prose, and policy interpretation. |
 | Public HTTP contract | `docs/api.md` | Routes, authentication, media types, request and response schemas, status codes, pagination, caching, idempotency, rate limits, and HTTP retry semantics. | Client walkthroughs, upstream or downstream integration internals, implementation detail. |
-| Consumer guidance | `docs/consumers/` | Choosing between Scriptorium's executable interfaces and understanding consumer responsibilities. | HTTP wire semantics, CLI syntax, Promptkit's Go package, and internal implementation detail. |
+| Consumer guidance for executable use and migration | `docs/consumers/` | Task-oriented executable use, migration to PromptKit, minimal examples, and consumer responsibilities. | HTTP wire semantics, CLI syntax, PromptKit's public Go API, external protocol contracts, internal implementation detail. |
-| External and durable integration contracts | `docs/integrations/` | Scriptorium-owned process and executable integration contracts. | Promptkit framework formats and outbound provider protocols, physical runtime placement, internal transformations, CLI syntax, and configuration defaults. |
+| Scriptorium-owned integration contracts | `docs/integrations/` | Scriptorium-owned executable and process contracts, logical output paths and schemas, media types, and compatibility. | PromptKit framework formats and outbound provider protocols, physical runtime placement and lifecycle, internal transformations, CLI syntax, configuration defaults. |
-| Implemented component inventory | `docs/internal/overview.md` | Current packages and components, their implemented responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
+| Inventory of implemented internal packages | `docs/internal/overview.md` | Implemented packages and components, responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
-| Internal component behavior | Other files under `docs/internal/` | Implementation flow, internal collaborators and state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
+| Behavior and architecture of internal packages | Other files under `docs/internal/` | Implementation flow, collaborators, state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
-| Architectural decision history | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
+| Architectural decision records | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
-| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status; sequencing; and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
+| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status, sequencing, and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
-| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other files intended to be copied or run. | Field-by-field reference, command reference, prose explanation. |
+| Release-note history | `docs/releases/` | One checked-in summary per source release under the procedure; the note at its immutable tag is the release record. | Current commands, behavior, contracts, and compatibility definitions. |
 | Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other copyable or runnable files. | Field-by-field reference, command reference, prose explanation. |
-Documents that do not exist are required only when the corresponding interface
+Create supporting documents for existing interfaces and responsibilities when
-or responsibility exists. Do not create placeholder API, consumer, integration,
+substantive content is available.
 or operations documents for behavior the application does not have.
 ## Boundary Rules
 ### Orientation
-The README owns product orientation. The developer guide routes contributors.
+Link among orientation, architecture, and internal documents; maintain each
-Architecture owns normative structure. Internal overview owns the current
+package or behavior description in its canonical owner.
 concrete component map. These documents may link to one another but should not
 maintain parallel package or behavior descriptions.
 ### Commands, Configuration, And Operations
@@ -119,26 +112,25 @@ other contracts.
 ### Releases
-The release policy owns release requirements; the release procedure supplies
+The release policy defines requirements and invariants that every release must
-the commands that satisfy them. Release notes are historical summaries, not
+satisfy. The repository-specific release procedure defines the commands and
-current-state contract owners. The checked-in note at an immutable tag records
+workflow maintainers use to satisfy that policy. Release notes record history
-that release; current documentation changes with the behavior it describes.
+at immutable tags. Maintain current behavior in its canonical documentation,
-Neither a procedure nor a note may weaken policy or defer required updates to
+update it with the corresponding behavior changes, and keep release procedures
-canonical contracts.
+consistent with adopted policy.
-### Open Source Attribution
+### Project Licensing And Upstream Attribution
-The [OSS policy](oss.md) defines the House Format and README and release-link
+README and release documents link to the canonical licensing and attribution
-conventions. Attribution entries own component-specific information. README
+materials under the [OSS policy](oss.md). The release procedure owns URL
-and release documents provide navigation to those canonical materials; the
+construction and publication mechanics.
 release procedure owns URL construction and publication mechanics.
 ### Contracts And Implementation
 Integration and API documents define externally observable shapes and
-semantics. Internal documents explain how this project implements or consumes
+semantics. Internal documents explain how this application implements or consumes those
-those contracts. Internal docs may name a field, file, or protocol to identify
+contracts. Internal docs may name a field, file, or protocol to identify a
-a dependency, but must link to its canonical contract for the definition.
+dependency, but must link to its canonical contract for the definition.
 ### Security Topics
@@ -160,31 +152,13 @@ Use sequentially numbered ADR filenames such as
 6. alternatives considered;
 7. consequences.
-Use one of these statuses:
+Treat the decision content of an accepted ADR as immutable. When a decision
-
+changes, create a new ADR and update the earlier ADR's status to superseded.
- **Proposed:** the decision is under consideration and may change;
+Rejected architectural alternatives belong in the ADR; rejected product ideas
- **Accepted:** the decision is approved, whether or not implementation is
+belong in the roadmap.
  complete;
 - **Rejected:** the proposed decision was considered and not adopted;
 - **Superseded:** a later ADR replaces the accepted decision.
 A proposed ADR transitions to accepted or rejected. An accepted ADR transitions
 to superseded only when a later accepted ADR replaces it. An ADR may be created
 as accepted when the decision has already been made.
 Treat the decision content of an accepted ADR as immutable. Its status and
 supersession metadata may be updated, but a changed decision requires a new ADR.
 A superseded ADR must link to its replacement, and the replacement must link
 back to the superseded ADR. Rejected architectural alternatives belong in the
 ADR; rejected product ideas belong in the roadmap.
 ## Maintenance
 Every policy document records its underlying template version and local
 last-updated date immediately below the title. Update the date when revising
 local policy; change the base version only when adopting a newer template.
 Do not retain template adoption instructions in the local policy.
 When behavior changes, update its canonical owner in the same change. If
 ownership moves, remove the old definition and replace it with a link where
 navigation remains useful.
--- a/docs/policy/meta.md
+++ b/docs/policy/meta.md
@@ -0,0 +1,27 @@
 # Policy Set Provenance
 **Base Policy Version:** 1.0
 **Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md
 ## Origin And Local Authority
 This repository's policy set is adapted from
 [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
 The adopted local policies govern work in this repository. Upstream revisions
 become local policy through deliberate adoption, preserving local decisions.
 Each policy's `Upstream Source` identifies its adopted baseline.
 ## Adoption And Updates
 For policy adoption, upstream revision reviews, and updates, consult the
 [upstream adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
 That guide and the reference example collection are maintained upstream and
 accessed through links. Keep discovery links pointed at the current upstream
 project and guide; keep adopted-source and example links pinned to commits.
 The local [developer guide](../development.md) routes tasks to applicable
 policies. Formal credit and licensing notices for the copied policy material
 belong in the local [attribution document](../oss/attribution.md).
--- a/docs/policy/oss.md
+++ b/docs/policy/oss.md
@@ -1,81 +1,150 @@
 # Open Source Licensing And Attribution Policy
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.8
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md
 ## Purpose And Scope
-This policy establishes a repeatable House Format for open source attribution
+This policy defines project licensing conventions and a repeatable House Format
-and license notices. It covers upstream components incorporated into or
+for upstream attribution and license notices. It covers the project's own code
-distributed with the project, including relevant transitive dependencies and
+and upstream components incorporated into or distributed with the application
-copied code or assets. Treatment follows the component's terms and actual use,
+or library, including relevant transitive dependencies and copied code,
-rather than its classification as a direct dependency.
+documentation, or assets.
 Determine treatment from the component's terms and actual use.
 Consulting development guidance or using tooling alone does not require an
 attribution entry. Copying or adapting documentation for inclusion in the
 repository is different: preserve its applicable attribution and license terms.
 A material's role as development guidance does not exempt copied documents.
 Apply any express permissions for attribution-free reuse of example formatting.
 The baseline is a publicly available source repository with releases published
 alongside it. The format is independent of language, forge, and build system.
 It does not require attribution for every development tool, establish license
-compatibility, or resolve obligations beyond attribution and notice handling.
+compatibility, or resolve every obligation arising from use or distribution.
 ## Canonical Locations
 The [documentation policy](documentation.md) assigns ownership:
- `LICENSE` contains the project's own license. Dependency attribution does
+- `COPYRIGHT`: project name, copyright statements, SPDX expression, grant,
-  not relicense the project.
+  warranty disclaimer, and third-party statement.
- `docs/oss/attribution.md` contains the canonical component entries.
+- `LICENSE` contains the complete, unmodified project license text, including
- `docs/oss/licenses/` contains complete, verbatim standard license texts,
+  incorporated companion text. Dependency attribution does not relicense the project.
-  including companion texts where applicable.
+- `docs/oss/attribution.md`: canonical component entries.
 - `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts.
 Use recognizable license filenames, such as `Apache-2.0.txt` or `LGPL-3.0.txt`.
 A shared standard text may serve multiple entries. Keep explanations outside
 license texts and preserve distinct versions and exceptions.
-## House Format
+## Upstream Reference Examples
-Each component entry has five fields:
+Use the commit-pinned upstream examples to create actual project notices.
 Retain their links and keep the example collection upstream; keep applicable
 license texts locally as specified above.
-1. **Project name**, normally as the entry heading.
+## Project Licensing
 Unless the author specifies otherwise, use **GPL version 3 or later**
 (`GPL-3.0-or-later`) for applications and **LGPL version 3 or later**
 (`LGPL-3.0-or-later`) for libraries. An author's explicit choice takes precedence:
 for example, a one-off script may use MIT. Such a choice requires no exception
 rationale, additional approval, or compensating controls under this policy.
 These defaults guide new license selection. Adopting this policy does not
 relicense existing code or override third-party terms. Preserve an existing
 license unless the author deliberately changes it. For mixed-purpose projects,
 follow the author's selected scope rather than inferring different licenses for
 individual packages.
 Use the upstream [application COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/application/COPYRIGHT)
 or [library COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/library/COPYRIGHT)
 to create the project’s root `COPYRIGHT` file.
 Use verified project names, contribution years, and copyright holders.
 For another selected license, adapt the grant, SPDX expression, disclaimer, and
 text references together to reflect the author's selected grant.
 For GPLv3 projects, copy the complete GPLv3 text into `LICENSE`. For LGPLv3
 projects, place the complete LGPLv3 text followed by the complete GPLv3 text in
 `LICENSE`; the LGPL incorporates the GPL terms. Keep the texts unmodified and
 place project-specific statements in `COPYRIGHT`. For the default grants, the
 grant and SPDX expression in `COPYRIGHT` must expressly identify `or-later`;
 follow the author’s choice if a different grant is selected.
 For other licenses, provide their complete text and any required project-specific
 fields; the standard reference collection remains unchanged. Keep `COPYRIGHT`,
 `LICENSE`, SPDX expressions, and README descriptions consistent with the actual
 grant. This convention introduces no blanket requirement for per-file headers;
 preserve notices or add them where the applicable terms require them.
 Identify separately licensed documentation or assets in the project grant, with
 links to their attribution and license information. An application's default
 code license does not override the terms of incorporated documentation.
 ## Upstream Attribution House Format
 Begin `docs/oss/attribution.md` with `# Open Source Attribution Notices`,
 followed directly by component entries. These comprise the complete document.
 Each entry presents these five fields in order, with blank lines between them:
 1. **Project name** as a level-two heading. An optional identification paragraph
   may follow, such as `Selected module: MODULE at VERSION.` with the module and
   version in backticks. For copied documentation, a concise `Material:` sentence
   may identify the affected files and whether they were adapted or copied
   without modification. A factual qualifier such as `(transitive dependency)`
   is permitted. Limit optional identification prose to factual component and
   material scope.
 2. **Upstream copyright statement or statements**, preserving their wording.
-3. **SPDX license identifier or expression**, when applicable.
+   Put multiple statements in separate paragraphs. Include this field when the
-4. **License and notice links**, covering the applicable standard texts and
+   selected upstream source supplies an applicable statement; otherwise, omit it.
-   upstream project-specific material.
+3. **SPDX license identifier or expression**, when applicable, using
-5. **Source repository link**, identifying the source corresponding to the
+   `SPDX-License-Identifier: EXPRESSION`.
-   imported version.
+4. **License and notice links**, beginning `License and notices:`, separated
   by ` | `, and ending with a period. Label local standard texts by license
   name, such as `MIT` or `Apache 2.0`. Label upstream files by their actual
   filenames, such as `COPYRIGHT`, `LICENSE`, `NOTICE`, or `PATENTS`.
 5. **Source repository link**, rendered exactly as `[Source](COMMIT_URL).`.
-Illustrative Markdown, with placeholders for the actual upstream information:
+Use the upstream [attribution example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/attribution.md)
 to create the project’s `docs/oss/attribution.md`.
 The example illustrates omitted fields and multiple copyrights and licenses.
 Replace the uppercase placeholders and illustrative URLs with actual component
 information. Local license links are relative to the destination
 `docs/oss/attribution.md`; copy the applicable texts into its `licenses/`
 directory. Do not copy example entries for components the project does not use.
-```markdown
+These are five fields, not a line limit. Omit the SPDX field when no applicable
-## Example Library
+identifier exists; identify nonstandard terms through the linked text. Preserve
 licensing alternatives and exceptions, and record a selected option when
 relevant through the factual license identification. Do not invent an identifier
 or silently resolve an unsettled licensing choice.
-Copyright <upstream copyright statement>
+Keep entries factual. Do not add agent-authored explanations of license
-
+expressions, file-level license scope, research performed, retained source
-SPDX-License-Identifier: Apache-2.0
+notices, or compliance conclusions. Avoid filler such as "none is invented
-
+here" and embellished link labels such as "upstream LICENSE", "additional
-License and notices: [Apache 2.0](licenses/Apache-2.0.txt) | [NOTICE](<upstream NOTICE URL at the imported commit>)
+patent grant", or "at the imported commit". Preserve actual required upstream
-
+content; this rule excludes editorial additions, not required notices. Policy
-Source: [Example Library](<upstream repository URL at the imported commit>)
+interpretation and exception reasoning belong in the adopted OSS policy or an
-```
+appropriate decision record, not the attribution document.
 These are five fields, not a line limit. Include multiple statements and links
 where needed. Omit the SPDX field when no applicable identifier exists; identify
 nonstandard terms accurately through the linked text. Preserve licensing
 alternatives and exceptions, and record a selected option when relevant. Do not
 invent an identifier or silently resolve an unsettled licensing choice.
 ## License Texts And Upstream Links
 Link standard license texts to their local copies. Link project-specific
-notices to the upstream copies instead of storing them locally. Every upstream
+notices to their upstream copies. Every upstream repository or notice link must
-repository or notice link must identify the exact commit corresponding to the
+identify the exact commit corresponding to the
 imported version, including the selected source revision for copied material.
 Do not use moving branches or version tags as substitutes for that commit.
-Classify material by its contents, not its filename. An upstream `LICENSE`,
+Classify material according to its contents. An upstream `LICENSE`,
 `COPYING`, or similar file may contain project-specific notices or exceptions
 in addition to standard wording. Link both the local standard text and the
 commit-specific upstream file when needed. Make companion license texts directly
-reachable from the entry rather than leaving readers to infer their location.
+reachable from the entry.
 For project-specific license and attribution material, this policy accepts
 direct links to the applicable upstream texts as satisfying reproduction,
@@ -91,17 +160,18 @@ source files; the central attribution entry does not authorize stripping them.
 ## Discoverability
 End the project's README with two friendly statements linking to its actual
-license and the attribution document. For Scriptorium:
+grant in `COPYRIGHT` and the attribution document. For example, for a project
 with the stated license:
 ```markdown
-Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
+Scriptorium is licensed under the [GPL v3.0 or later](COPYRIGHT).
 [Open Source attribution notices](docs/oss/attribution.md) are available.
 ```
 Each new checked-in release document and its hosted download page must end
-with links whose visible text is `LICENSE | ATTRIBUTION`. Use absolute URLs to
+with links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`. Use absolute
-those files at the release's immutable tag or corresponding immutable source
+URLs to those files at the release's immutable tag or corresponding immutable source
 revision so the links work in both locations. This release navigation is distinct
 from upstream component links, which must use the imported commit.
@@ -113,8 +183,9 @@ assets, source bundles, or a different binary package format.
 ## Maintenance And Exceptions
-Update notices in the change that adds, removes, upgrades, copies, or changes
+Update project licensing statements together when the author changes the grant
-the distribution of a relevant component. Check the selected source's license
+or its scope. Update upstream notices in the change that adds, removes, upgrades,
 copies, or changes the distribution of a relevant component. Check the selected source's license
 and notices rather than assuming they are unchanged. Update affected entries,
 commit links, and texts; retain historical versions through Git.
@@ -128,8 +199,10 @@ to implement this policy.
 Use the House Format routinely. Raise an exception only for a concrete obligation
 or unresolved rights question it does not address, including any arising from a
 particular distribution channel. Record the issue and selected treatment in the
-adopted policy or affected attribution entry as appropriate. Resolve the issue
+adopted OSS policy or an appropriate decision record. Attribution entries
-before the affected use or distribution without reopening settled choices.
+contain the resulting factual identification and required material, without
 repeating that reasoning. Resolve the issue before the affected use or
 distribution without reopening settled choices.
 Common ownership of projects is neither required nor a blanket exception.
 Apply the formatting convention prospectively. Do not rewrite published tags,
--- a/docs/policy/release.md
+++ b/docs/policy/release.md
@@ -1,8 +1,10 @@
 # Release Policy
-**Base Policy Version:** 1.2
+**Base Policy Version:** 1.4
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md
 ## Purpose
@@ -18,14 +20,13 @@ policy and link to it rather than introduce additional release requirements.
 A source release identifies one exact committed source revision through an
 immutable version tag and a version-matched, checked-in release note. The
-primary release branch is `main`; the authoritative publication remote is
+primary release branch is `main` unless the adopted policy specifies otherwise.
-`origin`.
+The procedure must name the authoritative publication remote.
 A successful push of the intended tag, with its source commit available on the
-authoritative primary branch, completes the release. Publish `main` before
+authoritative primary branch, completes the release. The source commit may be
-invoking the publication command; the command requires
+pushed before the tag or published together with it through an atomic push.
-that the remote branch exactly identifies the validated candidate and pushes
+The procedure must choose and document the supported approach.
 only the selected annotated tag.
 Release commands must finish at successful publication. They must not wait for
 or poll CI, require successful CI status, inspect downloadable artifacts, or
@@ -34,19 +35,20 @@ A failed or ambiguous push requires resolving the authoritative remote state
 before declaring success or retrying; successful pushes do not require a
 separate remote read-back gate.
-Scriptorium publishes Linux binaries and checksums asynchronously from the
+Repositories may publish source only. Additional binaries, images, packages,
-tagged source. The procedure must identify those deliverables and the
+checksums, or other declared deliverables may be published asynchronously from
 the tagged source. The procedure must identify those deliverables and the
 responsibility of their automation. Published deliverables must be traceable
 to that source and identify the same version.
-Artifact delivery is a separate status. A successful tag push is not evidence
+Track source-release completion and artifact delivery separately. Report delivery
-that artifacts are available. Delivery failures do not reverse source-release
+failures and optional investigations under artifact-delivery status.
 success, and optional investigation must not delay release completion.
 ## Versioning And Compatibility
 Stable releases use Semantic Versioning in the form `vMAJOR.MINOR.PATCH`, with
-no leading zeroes. Prereleases are not part of the adopted release channel.
+no leading zeroes. Prereleases require an explicit adopted policy defining
 their format and use.
 The selected version must be unused locally and on the authoritative remote.
 Do not require queries to every configured remote or publication service.
@@ -76,9 +78,13 @@ source tree. Use the complete version tag as the filename and begin with a
 title containing the product name and that exact version.
 Include a short summary and any relevant compatibility impact or upgrade
-instructions. Keep the note proportionate to the change. Fixed sections and
+instructions. Choose sections suited to the release and keep the note
-explicit no-action boilerplate are not required. Existing historical notes
+proportionate to the change.
-need not be rewritten to adopt this format.
+
 Keep exact current contracts in their canonical documents and update affected
 documentation with the behavior change. Link to those documents from the note
 where useful. If annotated tags are used, derive their summary from the
 checked-in note.
 Include the release footer defined by the [OSS policy](oss.md#discoverability)
 in each new release document and preserve it on the hosted download page. The
@@ -86,18 +92,11 @@ release procedure defines the concrete URLs and publication mechanics. Prepare
 these links with the release note; they do not add a network check or approval
 gate.
-Keep exact current contracts in their canonical documents and update affected
+Handle version selection, release-note content, and retirement of completed
-documentation with the behavior change. Link to those documents from the note
+roadmaps during preparation. Preserve planned and deferred work and repair
-where useful. A release note must not substitute for current documentation.
+affected links when retiring roadmaps. Reuse ordinary change review for
-Use annotated tags with their message derived from the checked-in note rather
+unintended files, credentials, and private data. Scope release-content review
-than requiring a separately authored account of the same release.
+to the tagged source.
 Version selection, release-note content, and retirement of completed roadmaps
 are preparation responsibilities, not separate human approval gates. Preserve
 planned and deferred work and repair affected links when retiring roadmaps.
 Ordinary change review covers unintended files, credentials, and private data;
 do not repeat it as a release-specific sign-off. Ignored local files are not
 prohibited merely because they exist: they are not included in the tagged source.
 ## Candidate Validation
@@ -107,24 +106,10 @@ mode or command may be provided for diagnosis, but must not be a required step
 before publication repeats the same checks.
 Run the complete deterministic, offline default test suite once for the final
-candidate, following the [testing policy](testing.md), and verify the required
+candidate, following the [testing policy](testing.md). For repositories that
-build targets. Select those targets for the application's actual support
+publish builds, verify the required build targets. Select those targets for
-commitments; native testing on each platform and access to particular hardware
+the application's actual support commitments; native testing on each platform
-are not default release prerequisites.
+and access to particular hardware are not default release prerequisites.
 The selected test invocation includes the race detector because the HTTP
 service shares engines and backend capacity state across concurrent requests.
 This single invocation covers both ordinary assertions and race detection.
 Build both declared Linux architectures with the hosted release flags to catch
 cross-compilation and packaging failures; native test hardware for each target
 is not required. Existing architecture tests enforce dependency boundaries.
 Retain narrow source guards against committed workspaces, vendor trees, and
 module replacements: these can otherwise make a passing local build depend on
 unpublished or substituted framework code. Disable workspace discovery and
 vendor mode during validation. These guards preserve the established
 cross-project boundary; they do not require exact dependency-version audits or
 module-metadata rewrites at release time.
 Additional gates must address a concrete risk that the existing checks do not
 adequately cover. Do not automatically require linting, race testing, module
@@ -134,8 +119,8 @@ checks when their distinct protection justifies their cost. A one-time migration
 check must not silently become a permanent release requirement.
 Release tests must not require real credentials, mutable application services,
-paid APIs, provider probes, or inference calls. The procedure describes
+paid APIs, provider probes, or inference calls. The procedure may describe dependency
-dependency preparation separately from offline validation.
+preparation separately from offline validation.
 Avoid duplicate validation across release phases. Successful checks for the
 same final candidate need not be repeated solely to satisfy another phase;
@@ -158,7 +143,9 @@ Automate the checks needed to publish the intended source under a fresh version:
 - the worktree and index are clean on the primary release branch;
 - the source being published is the exact candidate that passed validation,
  including its matching release note;
- the remote primary branch already identifies that exact candidate; and
+- the remote primary branch already identifies that candidate, or an atomic
  source/tag push will advance it to that candidate without discarding remote
  history; and
 - the tag identifies the validated candidate and only the intended refs are
  published.
@@ -211,3 +198,27 @@ Use copyable commands where practical. Keep optional diagnostics and consumer
 verification clearly optional. The procedure must not turn preparation work,
 ordinary change review, or post-publication investigation into additional
 release gates.
 ## Scriptorium Release Selections
 Scriptorium publishes stable releases from `main` through the authoritative
 `origin` push endpoint. The validated candidate is published to the remote
 branch before the annotated version tag; the publication command requires
 exact agreement between the remote branch and candidate before pushing only
 that tag. Atomic branch-and-tag publication and source-only delivery remain
 general alternatives in this policy, not Scriptorium-supported workflows.
 The tag message derives from the checked-in note. A successful tag push
 completes the source release; binary delivery is asynchronous and does not
 gate it.
 The tagged source produces Linux amd64 and arm64 binaries and checksums through
 the hosted workflow. Candidate validation runs the complete offline Go suite
 once with the race detector because concurrent HTTP requests share engine and
 backend capacity state. It builds both declared Linux targets. Narrow guards
 reject committed workspaces, vendor trees, and module replacements so local
 substitutions cannot mask unpublished framework code. These selected checks
 address distinct application and release risks; no CI polling, artifact
 availability, consumer installation, or new approval gate is required.
 The [release procedure](../release.md) owns exact commands, targets, guards,
 delivery reporting, and recovery steps.
--- a/docs/policy/testing.md
+++ b/docs/policy/testing.md
@@ -1,14 +1,16 @@
 # Testing Policy
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-28
 **Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md
 ## Purpose
 Our tests exist to make **incorrect changes expensive and correct changes cheap**.
-We do not optimize for test count, line coverage, exhaustive isolation, or the fewest possible tests. We optimize for sufficient confidence in important behavior while imposing as little unnecessary friction as possible on future development.
+We optimize for sufficient confidence in important behavior while minimizing friction on future development.
 ## Every test has a cost
@@ -22,9 +24,9 @@ Evaluate that tradeoff at two levels:
 1. **Per test:** What realistic defect does this test detect, how consequential would that defect be, and is that protection worth the test's lifetime cost?
 2. **Across the suite:** Does this collection provide materially more confidence than a smaller, simpler suite would?
-Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. They should not make ordinary internal changes needlessly expensive.
+Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. Keep ordinary internal changes inexpensive.
-The cost of a test is not a reason to omit testing by default. Do not cite maintenance cost abstractly. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
+Evaluate maintenance cost against the specific failure being protected. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
 ## Default testing style
@@ -56,7 +58,7 @@ To the extent the following features are present in the application, prioritize
 6. Previously observed or plausible regressions.
 7. Representative integration and end-to-end workflows.
-A package-level contract is behavior relied upon by another package or major collaborator, not every observable detail of a package implementation.
+A package-level contract comprises behavior relied upon by another package or major collaborator.
 Choose tests for requested behavior and established contracts. Tests must not
 introduce new restrictions, guarantees, or threat scenarios merely because they
@@ -75,14 +77,8 @@ Do not add tests merely because a function, branch, or line exists. Do not add a
 ## Choose the right test boundary
-Test through the narrowest stable boundary that expresses the behavior clearly.
+Choose the narrowest stable boundary that expresses the behavior clearly and
-
+provides durable confidence with minimal incidental coupling.
 For application configuration, ConfigKit owns exhaustive YAML grammar,
 source traversal, import/overlay composition, provenance, and inspection
 renderer tests. Scriptorium tests its selected definition, source discovery,
 CLI override presence, command prerequisites, runtime conversion, credential
 boundary, and representative execution/inspection workflows with the tagged
 library. Do not copy the upstream parser test matrix into this repository.
 This is often the package API, but it may instead be:
@@ -90,22 +86,15 @@ This is often the package API, but it may instead be:
 - a package-level operation when several internal collaborators jointly produce the behavior; or
 - a larger integration boundary when correctness emerges from interaction with a real dependency.
 Do not force all behavior through oversized end-to-end tests. Do not test every private helper merely because it exists. Choose the boundary that gives durable confidence with the least incidental coupling.
 ## Test behavior, not implementation
-A test should protect a decision, contract, or invariant. A test must not memorialize the current implementation.
+A test should protect a selected decision, contract, or invariant.
-A test is suspect when its main purpose is to detect that someone:
+A test is suspect when it primarily detects changes to private constants or
 helpers, equivalent operation ordering, incidental formatting, equivalent
 algorithms, or internal structure that preserves behavior.
- changed an internal constant;
+Behavioral tests should normally remain stable through internal refactoring that preserves the contract.
 - renamed or split a private helper;
 - reordered equivalent internal operations;
 - changed incidental formatting;
 - replaced one correct algorithm with another; or
 - refactored internal object structure without changing behavior.
 Refactoring should normally require no test edits unless the refactored structure is itself part of the contract.
 ## Expected effects of different changes
@@ -122,7 +111,7 @@ A test failing is not the same as a test needing to be edited. Many tests may co
 ## Separate mechanism from policy
-Configurable thresholds and defaults must not be duplicated throughout the test suite.
+Derive expectations from test-controlled configuration and relationships.
 For this example, assume the selected contract rejects a request to start more
 processes than a configured limit. Do not encode its production default indirectly:
@@ -158,33 +147,52 @@ limit solely to reproduce this example.
 The production default should be tested exactly only when its literal value is itself a public, operational, safety, protocol, or compatibility requirement.
-Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior, not duplicated literals.
+Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior.
 For established concurrency limits, distinguish these behaviors where the contract requires them:
 1. **Configuration handling:** values are accepted or rejected according to the selected contract.
 2. **Runtime enforcement:** observed peak concurrency never exceeds the configured limit.
-Use a test-controlled limit and measure the behavior relative to that limit. Do not merely assert today's default value.
+Use a test-controlled limit and measure the behavior relative to that limit.
-## Avoid semantic duplication across layers
+## Assign each behavior a test owner
-Each behavior should have a clear test owner.
+Where these layers exist, assign ownership as follows:
- Configuration tests own application YAML, strict decoding, discovery,
+- Parser tests own parsing cases.
-  precedence, and application defaults.
+- Validator tests own validation rules.
- CLI tests own argument mapping, streams, summaries, exit behavior, and
+- Domain tests own transformations and invariants.
-  representative command workflows.
+- Adapter tests own external integration behavior.
- HTTP tests own DTOs, strict decoding, limits, status mapping, and restricted
+- Orchestrator tests own coordination and failure propagation.
-  artifact policy.
+- CLI tests own argument and configuration mapping.
- Formatter tests own prepared-run and definition-inspection text and JSON
+- End-to-end tests prove that representative assembled workflows work.
-  presentation.
+
- Architecture tests own dependency direction and removal invariants.
+Give each layer its distinct responsibility and keep expectation updates localized to the contract being changed.
 ## Scriptorium Test Ownership
 - Application configuration tests own Scriptorium's definition, strict
  decoding at its boundary, source discovery and selection, explicit CLI
  override presence, application defaults, runtime conversion, and safe
  diagnostics. ConfigKit owns exhaustive YAML grammar, source traversal,
  import and overlay composition, provenance, and inspection renderers.
 - CLI tests own argument mapping, streams, output, exit behavior, and
  representative run, render, inspect, serve, and config workflows.
 - HTTP tests own DTO decoding, transport limits, status and error mapping,
  restricted artifact reading, and representative server workflows.
 - Formatting tests own prepared-run and definition-inspection text and JSON
  presentation. Architecture guards own dependency direction and removed
  framework-package boundaries.
 - Promptkit owns framework parsing, orchestration, validation, profiles, and
-  model-client behavior. Scriptorium's definition compatibility fixtures protect
+  model-client behavior. Scriptorium's definition and execution fixtures
-  its adapter plumbing without duplicating the upstream format contract.
+  protect adoption through its public adapter boundary without duplicating
  Promptkit's exhaustive format matrix.
-Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
+HTTP lexical containment, size limits, and shared engine and backend capacity
 across concurrent requests merit focused adapter coverage because violations
 cross a security or concurrency boundary. Choose cases by realistic risk
 rather than a coverage quota or a duplicated upstream matrix.
 ## Use test doubles deliberately
@@ -205,12 +213,9 @@ Mocks are appropriate when the contract includes facts such as:
 - an expensive API is called no more than once; or
 - a security audit event is emitted.
 Do not use mocks merely to isolate every object or reproduce the implementation's call graph.
 ## Go-specific guidance
-Select techniques according to the behavior and risk being tested. The following
+Select techniques by behavior and risk:
 are options, not a checklist that every package or application must satisfy:
 - table-driven tests for meaningful behavioral categories and boundaries;
 - `t.TempDir()` for real filesystem behavior;
@@ -220,55 +225,48 @@ are options, not a checklist that every package or application must satisfy:
 - integration tests where correctness depends on component interaction; and
 - a small number of representative end-to-end tests when assembled workflows expose meaningful risks not adequately covered at narrower boundaries.
-Avoid exact error-string assertions unless the wording is itself contractual. Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields.
+Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields. Use exact error-wording assertions only when the wording is contractual.
-At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Do not snapshot complete diagnostic wording unless it is contractual.
+At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Use complete diagnostic snapshots only when the wording is contractual.
 Golden-file updates must require an explicit local flag. CI must not update golden files automatically, and reviewers must inspect the semantic diff before accepting an update.
-Keep tests readable and direct. Test helpers and fixture frameworks must earn their own maintenance cost; do not build elaborate test infrastructure for small or isolated needs.
+Keep tests readable and direct. Size test helpers and fixture frameworks to the maintenance benefit they provide.
 ## Coverage
-Coverage is a diagnostic, not a target.
+Use coverage to locate untested critical branches and unexpectedly weak packages. Evaluate test quality through meaningful behavioral protection and choose coverage according to risk.
-Use it to find untested critical branches and unexpectedly weak packages. Do not write low-value tests solely to increase a percentage, and do not infer test quality from coverage alone.
+Pure domain logic will often warrant higher coverage than CLI wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
 Security-sensitive HTTP containment and external mappings may warrant denser
 coverage than straightforward process wiring. Uneven coverage is acceptable
 when it reflects risk.
 ## Regression tests
 A bug fix should normally include a regression test that fails before the fix and passes afterward.
-Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant; do not preserve accidental implementation details from the original bug.
+Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant.
-Not every historical bug requires a permanent test. If the underlying design has made recurrence impossible, the test has become redundant, or a stronger invariant test now subsumes it, remove or consolidate it.
+Remove or consolidate a test when the underlying design has made recurrence impossible, its protection is redundant, or a stronger invariant test subsumes it.
 ## Deleting or rewriting tests
-Tests are maintained code, not permanent historical artifacts.
+Delete or rewrite tests when maintenance cost exceeds their continuing
-
+protective value.
 Delete or rewrite a test when its maintenance cost exceeds the confidence it provides.
 Strong candidates include tests that:
 - require updates after harmless internal changes;
- directly assert private constants without protecting a real contract;
+- assert incidental private constants or snapshot large amounts of incidental output;
 - duplicate the same policy across several layers;
 - verify mock choreography rather than outcomes;
- snapshot large amounts of incidental output;
+- duplicate policy across layers, retest trivial helpers covered by package
- test trivial private helpers already exercised through stable package behavior;
+  behavior, or protect risks covered more effectively elsewhere;
 - protect risks already covered more effectively elsewhere;
 - are flaky, misleading, obsolete, or disproportionately expensive to diagnose; or
 - no longer correspond to a plausible failure mode.
-Several brittle tests may encode one genuine requirement. Replace them with one durable behavior-level or invariant test rather than preserving all of them.
+Several brittle tests may encode one genuine requirement. Consolidate them into one durable behavior-level or invariant test.
 ## Reviewing a proposed test
-Use the following questions when the value, boundary, or durability of a proposed test is not self-evident. Significant test additions should be reviewable against them, but written answers are not required for every routine test.
+Use the following questions when a proposed test needs closer evaluation. Significant test additions should be reviewable against them; written answers are optional for routine tests.
 1. Which requested behavior or established contract does it protect, and what realistic defect would violate it?
 2. How likely and consequential is that defect, and is it already protected elsewhere?
@@ -282,10 +280,9 @@ A test suite is sufficient when:
 - important requested behavior and established contracts are protected against realistic, consequential failures;
 - boundaries and component interactions have coverage where they introduce meaningful risks not protected elsewhere;
- failures provide useful signal rather than redundant noise;
+- failures provide useful, distinct signals;
- legitimate internal changes usually do not require test edits; and
+- tests usually remain stable through legitimate internal changes; and
 - additional tests would mostly repeat existing protection or preserve inconsequential implementation details.
-Sufficiency is a risk judgment, not a coverage percentage, test count, or required
+Reassess sufficiency as the application, its users, and the consequences of
-mix of testing techniques. Reassess it as the application, its users, and the
+failure evolve.
 consequences of failure evolve.
--- a/docs/release.md
+++ b/docs/release.md
@@ -23,20 +23,19 @@ Choose an unused stable version under the release policy. Commit its note as
 `docs/releases/<version>.md`, beginning with a title such as
 `# Scriptorium v0.14.0` (an example, not an instruction to select that version).
 Include a concise summary and relevant compatibility impact or upgrade action.
-End the note with the following footer, replacing `<version>` in both absolute
+End the note with the following footer, replacing `<version>` in all three absolute
 URLs with the selected version tag (for example, `v0.14.0`):
 ```markdown
-[LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/docs/oss/attribution.md)
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/docs/oss/attribution.md)
 ```
-Check that both URLs name files in the candidate tree at that tag. The tag may
+Check that all three URLs name files in the candidate tree at that tag. The tag may
 not resolve online until publication. The checked-in note is copied unchanged
 into the hosted release body by the existing workflow, so do not maintain a
 second footer there.
 Update affected canonical documentation with the change, and retire completed
 roadmap material when appropriate while preserving deferred work and links.
 No extra release-specific review signoff is required.
 Finish and commit the intended candidate on `main`, then publish that branch:
@@ -63,9 +62,8 @@ remote version, exact agreement with authoritative remote `main`, and a
 checked-in note whose first-level title contains Scriptorium and the exact
 version. Ignored local files do not make the candidate dirty.
-The existing source-boundary guards reject committed workspaces, vendor trees,
+The source-boundary guards reject committed workspaces, vendor trees, and
-and module replacements. No migration-specific exact Promptkit version audit
+module replacements.
 is required.
 It then runs the complete suite once with the race detector and builds Linux
 amd64 and arm64 binaries using `CGO_ENABLED=0`, `-trimpath`, and
--- a/docs/releases/v0.15.0.md
+++ b/docs/releases/v0.15.0.md
@@ -0,0 +1,26 @@
 # Scriptorium v0.15.0
 This minor release changes Scriptorium's application grant to GPL version 3 or
 later, aligns its repository policies and attribution notices, and updates the
 selected Promptkit and ConfigKit patch releases.
 ## Licensing and upgrade impact
 Scriptorium's application source and binaries are now distributed under
 GPL-3.0-or-later. Review [COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/COPYRIGHT)
 and [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/LICENSE)
 before redistributing or incorporating this version. Material adapted from
 Standard Repository Policies remains separately licensed under CC-BY-SA-4.0;
 the [attribution notices](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/oss/attribution.md)
 identify its scope and license text. Existing dependency grants are unchanged,
 and earlier tagged releases retain their own published terms.
 ## Dependency updates
 Scriptorium now selects Promptkit v0.11.2 and ConfigKit v0.4.2. The current
 [CLI](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/cli.md),
 [HTTP API](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/api.md),
 and [configuration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/config.md)
 references describe the executable contracts.
 [COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/oss/attribution.md)
--- a/docs/roadmap/configkit.md
+++ b/docs/roadmap/configkit.md
@@ -3,9 +3,10 @@
 ## Status And Intent
 Implemented feature direction, drafted on 2026-09-26 and delivered through the
-[implementation plan](implementation.md). This roadmap records the target
+historical plan at
-behavior and changes from the reviewed baseline; the implementation plan owns
+`git show 8452b54809b99425a97940da485daaa48c77aeb8:docs/roadmap/implementation.md`.
-sequencing, concrete interfaces, and verification evidence.
+This roadmap records the target behavior and changes from the reviewed baseline;
 that Git record owns sequencing, concrete interfaces, and verification evidence.
 The user is adopting ConfigKit across an application suite to standardize
 configuration semantics. Scriptorium will make a clean cutover to ConfigKit's
--- a/docs/roadmap/implementation.md
+++ b/docs/roadmap/implementation.md
@@ -1,536 +1,303 @@
-# ConfigKit Adoption Implementation Plan
+# Policy Alignment Implementation Plan
-## Status, Authority, And Historical Plans
+## Status, Scope, And Authority
-Planned on 2026-09-26 against Scriptorium commit
+Planned on 2026-09-28 against Scriptorium
-`43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c`. This document records the
+`8452b54809b99425a97940da485daaa48c77aeb8`. All five stages are complete.
-ordered implementation and its completion evidence. The maintainer resolved
+The ordered stages below retain the implementation instructions and completion
-the inspection-policy question:
+evidence for this delivered work set.
 `extra_params` remain visible; only API-key values require secret protection.
-The [feature roadmap](configkit.md) owns scope, target behavior, and user intent.
+The [feature roadmap](policy.md) owns the agreed end state, scope, and reasons
-This plan owns implementation steps and the interface choices needed to execute
+for local exceptions. This plan owns execution steps and acceptance checks.
-them. Read [development](../development.md) and every policy before work:
+This is documentation work, not application, dependency, or release-tool work.
 [agents](../policy/agents.md), [architecture](../policy/architecture.md),
 [documentation](../policy/documentation.md), [testing](../policy/testing.md),
 [release](../policy/release.md), and [OSS](../policy/oss.md).
 [ADR 0004](../adr/0004-definition-boundary.md) continues to govern Promptkit's
 definition boundary. Do not rewrite accepted ADR decisions.
-This filename previously contained completed Promptkit plans. Older roadmap
+The selected public upstream revision is
-links to this file refer to these historical records, not the ConfigKit stages:
+`d84a38ebab26f048cafbe59a2246700c35d29843`.
 Start with its
 [adoption guide](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md).
 Retrieve source files at this revision, not whatever main contains when a
 stage runs. A verified checkout of this exact revision is acceptable; no
 sibling checkout is a prerequisite. If source retrieval fails, report that
 blocker rather than inventing source content or provenance.
- Completed v0.11 implementation and release handoff:
+Read the current local agent policy and developer orientation before work,
-  `git show 43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c:docs/roadmap/implementation.md`.
+then policies governing the stage. Once Stage 2 lands, use the new selective
- Completed v0.9 implementation:
+reading guide. Reuse unchanged policy text already available in context.
  `git show e4405966c87c8a7843b340146e90cc1e515bef42:docs/roadmap/implementation.md`.
-Those deliveries must not be repeated or lost from upcoming release preparation.
+## Historical Implementation Records
 These Git records are available locally without publishing the recent commits.
-## Working Rules And Selected Design
+This filename previously held completed application plans. Preserve their
 records through Git rather than carrying their implementation steps forward:
-The dependency target is `gitea.maximumdirect.net/eric/ConfigKit v0.4.0`,
+- ConfigKit adoption and release handoff:
-commit `e6ced0d3d1194b58e0b3dc8970089471ba175258`. Use its public root package,
+  `git show 8452b54809b99425a97940da485daaa48c77aeb8:docs/roadmap/implementation.md`.
-imported as `configkit`. The roadmap links the exact upstream contracts.
+- Earlier PromptKit plans are referenced within that historical document.
 Do not opportunistically upgrade Promptkit or other dependencies, commit a
 workspace/replacement, or depend on sibling source at runtime.
-This is a clean configuration cutover, not a compatibility project. Native
+Those stages must not be rerun. Existing release notes, including
-ConfigKit syntax, presence, nullability, resource limits, and precedence apply.
+[the v0.14.0 note](../releases/v0.14.0.md), record prior delivered features.
-Do not add a pre-parser, YAML serialization round trip, alternate merge engine,
+Do not infer a new release obligation from an old prospective handoff.
-legacy mode, generic provider abstraction, or a new CLI framework.
+The new policy and licensing changes still need a concise summary in the next
 release, including the already-selected GPL-3.0-or-later application grant and
 the separately licensed policy material. Version selection and publication
 are not part of this plan.
-Keep application source discovery and domain rules in `internal/config`;
+## Common Execution Rules
 CLI parsing/output stays in `internal/adapter/cli`. Promptkit remains responsible
 for prompt/profile/schema parsing, backend semantics, credentials, and engine
 behavior. Keep one shared server engine and existing HTTP artifact policy.
 No HTTP schema, execution-report, request-timeout, or retry-orchestration change
 is part of this plan.
-For every stage:
+1. Inspect status and relevant diffs before each stage. Preserve unrelated
   changes; do not silently include them in the stage commit.
 2. Read the selected upstream files completely before adopting them. Compare
   directly with local files; do not reconstruct historical adoption baselines.
 3. Start from upstream text, remove the complete Base Policy Template section,
   and apply only the customizations selected below. Preserve shared language
   verbatim, including its meaning and strength. Do not retain old paraphrases
   merely because they are familiar or add prohibitions for hypothetical risks.
 4. For each policy adopted in that stage, set the target Base Policy Version,
   the actual adoption date, and an Upstream Source link:
   `https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/FILE.md`.
   Substitute the actual filename. Do not stamp a source on a policy before
   incorporating it. Intermediate commits may legitimately have mixed versions.
 5. Update the single policy-attribution entry as its copied/adapted scope grows.
   Do not claim later-stage material has already been adopted.
 6. Validate affected text, links, notices, and diff; record concise completion
   evidence under the completed stage here. Commit each coherent stage with a
   short plain-English message under the agent policy. Do not push or publish.
-1. Inspect the working tree and relevant code/tests through the repository's
+Do not change Go code, module pins, tests, release scripts, CI, accepted ADR
-   code-discovery guidance. Preserve unrelated changes.
+decisions, or published release notes. Do not introduce recurring sync checks,
-2. Implement the listed outcome and only supporting refactoring it needs.
+license approval rounds, release gates, or blanket source headers. Preserve
-   Internal names below are selected implementation guidance, not public APIs
+the application grant and dependency terms. Standard license text must remain
-   or immutable package-layout contracts.
+verbatim even if a generic whitespace check dislikes publisher formatting.
 3. Update canonical current-state docs when behavior lands. Until Stage 3 the
   new loader is internal preparation, not an advertised executable feature.
   Never claim later stages are implemented.
 4. Run focused tests and the development guide's baseline validation for code
   changes. Tests stay offline, deterministic, and free of real credentials.
   Reuse existing coverage rather than cloning ConfigKit's parser test matrix.
 5. Format changed Go files, inspect the diff, validate affected docs/examples,
   record stage status/evidence here, and commit the coherent unit. Do not push,
   tag, publish, or add new release gates.
-### Application Configuration Definition
+## Stage 1: Adopt OSS Rules And Establish Licensing Notices
-Use a new `Document` type in `internal/config` for the native configuration
+**Status: Complete.** OSS language was compared with the pinned source after
-shape. It replaces the old on-disk `Config` after CLI cutover. Keep the familiar
+the approved metadata and example changes. The CC-BY-SA text matches its pinned
-YAML field names:
+source byte-for-byte; attribution and navigation were checked against the
 specified format and local paths.
-| YAML path | Go shape | Default and selected meaning |
+Files: `docs/policy/oss.md`, `docs/oss/attribution.md`,
-| --- | --- | --- |
+`docs/oss/licenses/CC-BY-SA-4.0.txt`, `COPYRIGHT`, `README.md`,
-| `prompt_dir`, `profile_dir` | `string` | Empty; no source configured. |
+and the footer portion of `docs/release.md`.
 | `schema_dir` | `string` | Existing schema-directory default. Empty remains empty at the application boundary; Promptkit owns any subsequent framework default. |
 | `transient_retries` | `*int` | Nil; omitted/null delegates, zero disables additional attempts. |
 | `server` | Non-pointer struct | Its children receive typed defaults; null is invalid. |
 | `server.addr` | `string` | Existing listen-address default when absent; explicit empty is passed unchanged to the standard HTTP server, not replaced with the Scriptorium default. |
 | `server.artifact_root` | `string` | Empty; HTTP file input remains disabled. |
 | Three `server.max_*_bytes` fields | `int64` | Existing defaults; explicit zero disables the respective limit; null is invalid. |
 | `defaults` | Non-pointer struct | Contains `render_format`; null is invalid. |
 | `defaults.render_format` | `string` | Existing text default; resolved value must be text or json. Explicit empty is invalid, not defaulted. |
 | `backends` | `map[string]BackendDocument` | Nil; null is permitted, an empty mapping follows ConfigKit semantics. |
-`BackendDocument` keeps `endpoint string`, `api_key_env string`,
+1. Read upstream OSS v1.8, COPYRIGHT, the canonical
-`extra_params map[string]any`, `concurrency_limit int`, and
+   `examples/licensing/policy-attribution.md`, and referenced licensing
-`queue_capacity *int`. Scalar nulls are invalid; nullable maps/pointers retain
+   examples at their pinned URLs. Adopt OSS v1.8 with metadata as above.
-native semantics. No catalog IDs or Promptkit fields are added.
+   Remove template-only content; retain upstream common wording and its
   existing commit-pinned example links. Customize the README example to
   Scriptorium and GPL v3 or later. No other OSS exception is selected.
 2. Copy the complete CC-BY-SA-4.0 reference text from the selected revision
   into the named local license file and compare it byte-for-byte with that
   source. Do not copy the rest of the reference collection or add CC0 merely
   because example formatting is used.
 3. Reformat the attribution document to the exact v1.8 House Format. Use
   `# Open Source Attribution Notices`, immediately followed by entries.
   Place Standard Repository Policies first, using the canonical entry,
   with its COPYRIGHT, LICENSE, and Source URLs pinned to the selected full
   commit. In this stage identify `docs/policy/oss.md` as the newly adapted
   material. Do not research or make claims about prior adoption provenance.
 4. Preserve the eight existing dependency entries and their imported commits,
   copyright wording, SPDX expressions, and required notices. Optional module
   identification paragraphs may retain versions currently in source labels.
   Remove the introductory prose, missing-copyright filler, and editorial
   YAML license explanations. Preserve the factual MIT AND Apache-2.0
   expressions. Use actual upstream filename labels, local license names,
   terminal periods, and the exact `[Source](COMMIT_URL).` source form.
   Do not upgrade dependencies or relabel their grants.
 5. Add a scoped paragraph to COPYRIGHT stating that material adapted from
   Standard Repository Policies remains CC-BY-SA-4.0, with
   `docs/oss/attribution.md` identifying affected material and links. This
   covers the scoped material as stages add it; it does not relicense unrelated
   application code or documentation. Keep the existing GPL grant and LICENSE.
 6. Correct the README ending to link GPL v3 or later to COPYRIGHT and keep
   the attribution link. Change the release-procedure footer to absolute
   immutable-tag COPYRIGHT, LICENSE, and ATTRIBUTION links, updating the
   references to the number of URLs. Change no publication commands.
   Do not retrofit published notes or create a release note/version now.
-The fresh defaults factory reads existing `internal/defaults` and format
+Acceptance: OSS text matches the pinned source except the approved project
-constants, not a duplicated set of literals. Normalization trims surrounding
+example and metadata; attribution follows the prescribed format; the added
-whitespace from application directory strings, artifact root, and server
+license text is faithful; project and dependency grants remain unchanged.
-address; cleans only nonempty application paths; and lowercases/trims
+Check affected local paths and upstream notice/example destinations. Missing
-`defaults.render_format`. Empty paths remain empty: never let
+copyright fields are omitted, not explained with agent-authored commentary.
 `filepath.Clean("")` turn disabled/unset into `.`. Record actual changes with
 `configkit.Normalize`, using value-free reasons. Do not normalize backend
 fields or parameter values on Promptkit's behalf.
-The read-only validator reports negative application size limits, negative
+## Stage 2: Adopt Provenance, Agent Guidance, And Documentation Ownership
 nonnull application retries, and invalid render format through
 `Validation.Error` at their field paths. It does not print rejected values.
 Do not call the existing format parser's empty-as-default branch for this field.
 Do not add endpoint, backend ID, credential-presence, directory-existence,
 address-format, or positive-only-capacity checks. Existing Promptkit and
 command-specific validation retains those responsibilities where applicable.
-## Stage 1: Add The Dependency And Native Application Definition
+**Status: Complete.** The three policies carry the selected versions, source
 links, and local adoption date; shared text and the orientation template were
 compared with the pinned source. The seven-link reading guide and local links
 were checked, and attribution names only the incorporated material.
-**Status: Complete.** The pinned dependency, native definition, focused
+Files: new `docs/policy/meta.md`, `docs/policy/agents.md`,
-presence/normalization/validation tests, and commit-specific attribution are in
+`docs/policy/documentation.md`, root `AGENTS.md`,
-place. The existing executable loader remains active pending the command cutover.
+`docs/development.md`, and the policy attribution entry.
-Primary files: `go.mod`, `go.sum`, new focused files under `internal/config`,
+1. Adopt meta v1.0 and agents v1.3 verbatim after template-section removal
-and `docs/oss/attribution.md`.
+   and metadata substitution. Keep meta's live project and main-branch
   adoption-guide discovery URLs; its own Upstream Source is commit-pinned.
   Retain local relative links to developer guidance and attribution.
 2. Adopt documentation v1.11. Customize only applicable topic-map rows:
   configuration remains application configuration, framework formats belong
   to PromptKit, consumers cover executable use and migration rather than a
   Scriptorium public Go API, and integrations cover Scriptorium-owned
   executable/process contracts. Keep upstream rows for meta, COPYRIGHT,
   LICENSE, and attribution. Remove instructional “if applicable” qualifiers
   from selected rows. Preserve the rest of the shared language.
 3. Use the upstream ADR lifecycle and examples guidance without retaining
   generic local expansions. This does not edit accepted ADRs or change their
   decisions. Metadata maintenance follows the adoption guide through meta,
   rather than a duplicate custom rule set.
 4. Adapt upstream `agents/AGENTS.md` into root AGENTS.md. Preserve any actual
   repository-specific code-discovery instructions; do not copy environment-
   injected instructions into the file just because they appeared in a session.
   Do not copy upstream's own root AGENTS.md.
 5. Add the adoption guide's Policy Reading Guide table and selection bullets
   verbatim to the developer guide with the seven local links. Replace its
   unconditional architecture-reading instruction and duplicated policy-reading
   prose with this selective guide. Retain project orientation, task-specific
   contract rows, dependency boundaries, and baseline validation commands.
   Avoid maintaining competing policy trigger rules in multiple places.
 6. Expand the policy entry's Material sentence to identify the adopted OSS,
   meta, agents, and documentation policies plus adapted root AGENTS.md and
   the copied Policy Reading Guide section of docs/development.md. Mark them
   adapted for this repository; do not imply the whole developer guide or
   unrelated tooling instructions have changed license.
-1. Add ConfigKit at the selected release. Retain Promptkit v0.11.0 and its
+Acceptance: all stage policies have their own correct source link and version;
-   selected catalogs. Provision dependencies outside offline test execution.
+orientation selects policies by task, including meta for adoption work; local
-   ConfigKit's yaml/v4 release-candidate dependency is the reviewed upstream
+links resolve; no upstream handbook or example collection was copied.
-   choice, not an instruction to upgrade its parser independently.
+Generic language differences from upstream are eliminated, not rephrased.
 2. Implement `Document`, `BackendDocument`, the fresh defaults factory,
   recorded resolver, and read-only validator described above. Keep the old
   loader operational until Stage 3 so this stage remains independently
   buildable; this temporary development state is not a shipped compatibility
   mode or a second user-selectable configuration path.
 3. Test the new definition using real `configkit.Load[Document]` with
   `Bytes` and `NoSource`. Cover explicit zero/empty/null distinctions,
   retry/queue nil-versus-zero, safe application validation, and a normalized
   path whose effective output agrees with the returned value. Include nested
   unknown fields and a representative dynamic numeric parameter.
 4. Add ConfigKit and yaml/v4 attribution from their selected source material.
   Resolve the imported yaml/v4 commit from release/module metadata. Preserve
   actual copyright statements; do not infer a project statement from the
   FSF license-document copyright. Use applicable SPDX expressions, local
   standard texts, and commit-pinned upstream license/notice links. Reuse GPL,
   LGPL, MIT, and Apache texts where applicable, including companion links.
   Retain yaml.v3 attribution because Promptkit still incorporates it.
 5. Document the internal definition as preparation in the relevant internal
   guide without claiming the CLI has switched. No current configuration
   contract changes yet.
-Acceptance: the dependency and definition compile, focused tests demonstrate
+## Stage 3: Adopt Architecture And Testing With Narrow Local Decisions
 native semantics and audited normalization, and attribution follows the OSS
 policy. Existing executable behavior still passes its tests.
-## Stage 2: Build Discovery And The Shared Loading Boundary
+**Status: Complete.** The three shared architecture sections and the common
 testing text match the pinned source. Local architecture decisions were checked
 against the accepted ADRs and internal guides; focused test ownership and the
 expanded attribution scope were reviewed without changing application code.
-**Status: Complete.** Ordered source discovery, one ConfigKit load, typed
+Files: `docs/policy/architecture.md`, `docs/policy/testing.md`,
-diagnostics, and settings conversion are covered by focused file/default and
+policy attribution entry, and focused internal docs only if moving existing
-override tests. Existing commands still use the old entry point until cutover.
+implementation detail requires it.
-Primary files: `internal/config` and its tests; `docs/internal/sources.md`.
+1. Read the existing architecture, relevant accepted ADRs, source/adapter
   internal guides, and the pinned architecture v1.3 template. Retain upstream
   Purpose And Ownership, Architectural Approach, and Adopted Constraints And
   Implemented Structure text verbatim. Replace the Application-Specific
   Topics placeholder with Scriptorium's existing substantive decisions.
 2. Preserve public PromptKit/ConfigKit responsibility boundaries, definition
   support, strict decoding, presence handling, HTTP artifact containment,
   request independence and concurrency-safe shared capacity, credential/error
   boundaries, dependency restrictions, and explicit workflow non-goals.
   Retain the existing lexical containment and privileged-host threat scope,
   not a stronger filesystem-sandbox promise. Customize the trust discussion
   to those decisions rather than retaining instructional example prose.
 3. Correct system shape to include run, render, serve, inspect, and config.
   Link to internal documentation for concrete package inventory/mechanics.
   Where material moves, preserve it in its canonical internal owner without
   duplicating it. Do not introduce new wrappers, ports, orchestration, or
   package constraints merely to “implement” the architectural recommendation.
 4. Adopt testing v1.3 common text verbatim. Add one clearly identified local
   test-ownership section for configuration, CLI, HTTP, formatting, architecture
   guards, and PromptKit/ConfigKit boundaries. Preserve the existing distinction
   between adoption/integration fixtures and upstream exhaustive tests.
   Retain a short application-specific note explaining HTTP containment and
   shared-state risks where useful; do not replace upstream risk-based coverage
   guidance or create percentage targets, quotas, or new test requirements.
 5. Add accurate source/version/date metadata and extend the policy attribution
   scope to architecture and testing. Record any moved adapted prose in the
   Material scope if it is placed outside the already identified files.
-1. Add `LoadOptions` with `Path string`, `Explicit bool`, `Overlay string`,
+Acceptance: direct comparison isolates only the roadmap's justified local
-   and `Overrides []configkit.Override`, plus
+decisions; shared text matches upstream. Architecture describes existing
-   `Load(LoadOptions) (*configkit.Result[Document], error)`.
+behavior accurately without implementation work. Testing preserves ownership
-   Discovery chooses a source; the one ConfigKit call owns actual file reading
+without duplicating upstream matrices or imposing new coverage gates.
   and decoding. Return the result so consumers retain the frozen inspection
   snapshot as well as the typed configuration.
 2. With `Explicit=true`, pass the selected path to `configkit.File`;
   an explicitly empty path is invalid, not implicit discovery or a fallback
   to the old system filename. Do not silently trim a source filename into a
   different filename. ConfigKit validates and resolves file sources.
 3. With `Explicit=false`, ignore the option's path value and examine the
   existing ordered implicit search locations. Only nonexistence permits
   examining the next candidate. Other stat failures are errors. Select the
   first existing candidate and let ConfigKit load it. A selected file's later
   disappearance/read/parse failure does not restart discovery.
 4. If neither implicit candidate exists, use `NoSource`. Initially leave
   imports disabled and the overlay empty; Stage 4 enables composition.
   Defaults-only loads still accept explicit application overrides. Never
   reinterpret an empty file as `NoSource`.
 5. Pass overrides into the ConfigKit call before decoding/validation; do not
   validate a separately merged lower configuration first. Native parsing and
   composition failures still follow the upstream lifecycle and are not
   bypassed by CLI overrides.
 6. Add a small `Settings(Document) AppSettings` conversion for existing
   executable wiring. It copies resolved fields, maps the already-validated
   format, and converts the backend map into ID-sorted backend settings.
   It performs no file IO, normalization, credential lookup, semantic backend
   checks, or additional defaults. Dynamic values retain their decoded shapes.
 7. Preserve ConfigKit's typed `*LoadError` through wrapping so the CLI can
   render safe structured diagnostics. Discovery-only errors are concise and
   quote paths safely; no new public error taxonomy is needed.
 8. Test ordered discovery with temporary paths rather than host system files,
   explicit missing/empty paths, empty-file rejection versus `{}`,
   defaults-only loading, source records, override-before-validation behavior,
   sorted backend conversion, and preservation of zero/nullable values.
   Remove no existing entry point until all its CLI callers migrate in Stage 3.
-Acceptance: real files and defaults-only inputs produce one reusable result,
+## Stage 4: Adopt Release Policy Without Changing Publication Behavior
 runtime conversion agrees with it, and tests do not depend on machine-wide
 configuration or secrets. The old and new internals are temporarily buildable,
 with no new user-visible mode.
-## Stage 3: Cut Existing Commands Over And Remove The Legacy Loader
+**Status: Complete.** The shared release language matches the pinned source;
 the local selections match the existing script, hosted workflow, and runbook.
 Commands, build targets, recovery behavior, and the three-link footer remain
 unchanged. Attribution now names all seven adopted policies.
-**Status: Complete.** All five command modes use the shared ConfigKit loader;
+Files: `docs/policy/release.md`, `docs/release.md`, attribution entry.
 the legacy decoder and merge path are removed. CLI and configuration contracts
 now describe native YAML and override behavior. Full test, race, vet, build,
 and diff checks passed.
-Primary files: `internal/adapter/cli/run.go`, `inspect.go`,
+1. Read the current release policy, procedure, script, and hosted workflow;
-`internal/config/config.go`, and associated tests.
+   inspect them read-only. Adopt upstream release v1.4 common wording.
 2. Add a compact Scriptorium-specific section preserving the established
   selections: main/origin, branch-before-tag publication with exact remote
   candidate agreement, annotated tags derived from the checked-in note,
   stable releases only, asynchronous Linux binaries/checksums, one race-enabled
   offline test invocation, and source-boundary guards. Keep rationale for
   selected gates in policy and command/target details in the procedure.
 3. Retain upstream's general alternatives verbatim but state which existing
   approach Scriptorium selects. Atomic push and source-only release remain
   template-supported alternatives, not newly supported Scriptorium workflows.
   Preserve successful tag publication as completion; no CI polling, artifact
   availability, or consumer installation gate is added.
 4. Align the procedure with this allocation without changing its commands,
   required checks, supported platforms, or failure-recovery behavior. Confirm
   the Stage 1 three-link footer survives hosted-body reuse. Do not run the
   publication command or mutate remote state to validate documentation.
 5. Add metadata and expand the policy attribution scope to all seven policies.
   The final Material description also identifies adapted AGENTS.md and the
   developer-guide reading section, plus any actually moved adapted text.
-1. Route run, render, serve, inspect prompt, and inspect profile through the
+Acceptance: the existing release workflow still satisfies the resulting policy
-   shared `Load` and `Settings` boundary. Preserve the explicit presence of
+with no script/CI changes. Source completion, delivery status, immutability,
-   `--config` in every parser. Centralize the small application-flag mapping
+tag type, and validation obligations are unchanged. All seven source links
-   rather than reproduce it in each command.
+identify their own file at the selected full commit.
 2. Use `flag.FlagSet.Visit` (or the existing explicit-set helper) to create
   one `configkit.Override` per explicitly supplied application flag. Use
   `configkit.Keys`, built-in scalar values, and a safe `Flag` label containing
   only the flag name. Standard flag parsing's last occurrence supplies the
   single override; do not emit duplicate records or parser defaults.
-   | Flag | Application path | Existing command scope after cutover |
+## Stage 5: Verify Language Parity And Complete The Documentation Handoff
   | --- | --- | --- |
   | `--prompt-dir` | `prompt_dir` | run, render, serve, inspect prompt |
   | `--profile-dir` | `profile_dir` | run, render, serve, inspect profile |
   | `--schema-dir` | `schema_dir` | run, render, serve |
   | `--addr` | `server.addr` | serve |
   | `--artifact-root` | `server.artifact_root` | serve |
   | `--max-request-bytes` | `server.max_request_bytes` | serve |
   | `--max-artifact-bytes` | `server.max_artifact_bytes` | serve |
   | `--max-response-bytes` | `server.max_response_bytes` | serve |
-   Register the schema-directory flag on render as well as run/serve so the
+**Status: Complete.** All seven policies were compared directly with the pinned
-   advertised application path override is consistently usable. This is not a
+upstream files; differences are limited to metadata, removed template text,
-   general expansion of runtime/provider flags to other commands.
+the selected project example and topic rows, and the identified local sections.
-3. Keep `--format`, `--out`, request `--transient-retries`, prompt/profile
+The copied license matches byte-for-byte. A Markdown-aware check resolved 86
-   selection, model overrides, timeouts, inputs, variables, and reporting
+local links; historical plan references resolve to Git objects. Attribution,
-   options outside the application configuration tree. In particular,
+notice scope, release navigation, and the final documentation-only diff were
-   `render --format` overrides that invocation's output format without
+reviewed without changing application or publication artifacts.
   rewriting `defaults.render_format`; omitted format inherits its resolved
   application value. Existing invocation-only parsing remains unchanged.
 4. Remove post-load directory trimming/cleaning/defaulting from argument
   finalizers, including unconditional schema-path cleaning. Keep only
   invocation-owned transformations such as output-file paths. Explicit
   empty profile/artifact-root overrides must clear file-provided values;
   explicit empty prompt directory must reach the existing execution
   prerequisite rather than revive the lower value.
 5. Keep existing command prerequisites: run/render/serve and prompt inspection
   need their effective prompt directory as currently required; profile
   inspection does not acquire a prompt-directory requirement. All commands
   still perform the common application schema validation. Do not introduce
   eager filesystem or credential validation for inspection.
 6. Add one CLI diagnostic path using `errors.As` and
   `configkit.WriteDiagnostics` for load errors. Carry successful load warnings
   to the command boundary and render them once on stderr before execution or
   output. Handle diagnostic writer errors as command failures. Do not flatten
   structured failures into raw parser text or print rejected values.
   Preserve existing process exit classifications; application/parse/load
   failures are exit 1, not generated-output validation exit 2.
 7. Remove the old YAML decoder, `strictInteger.UnmarshalYAML`, old on-disk
   types, `applyConfig`, `ApplyCLIOverrides`, and unused compatibility
   sentinels/helpers after migrating all callers/tests. Keep only one defaults
   factory. Remove the direct yaml.v3 import; module tidy may retain yaml.v3
   as an indirect Promptkit dependency.
 8. Update tests to the deliberate breaking semantics, not the legacy behavior.
   Protect explicit empty path clearing, scalar-null rejection, unknown fields,
   rejected empty/multi-document input, one representative YAML policy change,
   unchanged request-versus-engine retry precedence, absent optional
   credentials, and command-specific inspection prerequisites.
 9. Update configuration and CLI contracts, source/adapter internals, architecture
   ownership, and the contributor reading guide for the delivered cutover.
   Preserve existing application defaults, Promptkit definition support,
   HTTP containment, shared capacity, and report behavior. Adjust the current
   CLI claim that every command requires a prompt directory to match actual
   command-specific requirements.
-Acceptance: all existing commands use ConfigKit, no legacy parser or second
+Files: this plan, the feature roadmap, and only affected documentation needing
-application merge remains, relevant tests pass, and diagnostics and docs describe
+correction within the preceding stages' scope.
 the native breaking behavior. Imports/overlays and new inspection commands are
 not yet advertised.
-## Stage 4: Enable Explicit Imports And Selected Configuration Overlays
+1. Compare all seven adopted documents directly with their selected upstream
   counterparts. Account for metadata, removed template sections, approved
   substitutions, and the narrow local sections. Correct every remaining
   non-substantive wording difference. Do not turn this comparison into a
   permanent script, CI requirement, or release gate.
 2. Check there are no adoption placeholders, copied template-only instructions,
   absent local example links, stale BSD descriptions of Scriptorium itself,
   or contradictory selective-reading directions. Legitimate BSD dependency
   attribution remains. Validate links using Markdown-aware handling so
   illustrative syntax in inline code is not treated as a broken real link.
 3. Confirm per-document source metadata, the policy entry's exact scope,
   COPYRIGHT's scoped license treatment, existing dependency grants/notices,
   and the byte-for-byte new license text. Keep example/source links pinned
   and public discovery links current. Check footer paths in the candidate;
   unpublished release tags need not resolve online.
 4. Review affected roadmap references to implementation.md. Where a link
   specifically means an old completed plan, replace it with a clear historical
   Git reference from this plan, not this new policy sequence. Preserve
   deferred application features and historical completion evidence.
   Current release directions link to the canonical procedure, not an old
   two-link footer. Do not rewrite published release notes.
 5. Mark only actually delivered stages complete with concise evidence here.
   Update the feature roadmap's status to delivered and keep its end-state
   focus. Record the next-release summary described above without choosing a
   version, creating a tag, or claiming publication.
 6. Run diff/whitespace and affected-document/link checks. Do not reformat
   verbatim license text to satisfy a style check. No Go test/build rerun is
   necessary for this documentation-only work; no executable example or
   publication command needs changing. Inspect status and staged diff, commit,
   and report the commit and remaining work under the agent policy.
-**Status: Complete.** File-backed loads support explicit imports and one
+Acceptance: policy language is standardized with only justified local
-selected overlay under the selected file's canonical directory. All five
+customization; notice/provenance arrangements describe reality; no runtime,
-existing command modes accept `--config-overlay`; real-file composition and a
+dependency, publication, or historical-release change slipped into the diff.
 render workflow are tested. The composed example and contracts are updated;
 full test, race, vet, build, and diff checks passed.
 Primary files: shared loader, CLI source-selection wiring, configuration and
 CLI tests, maintained configuration examples.
 1. Enable `Options.Imports` for file-backed loads. Leave it false for
   `NoSource`, which rejects imports. Use ConfigKit's default canonical
   selected-file directory as the root; do not supply a wider filesystem root
   or add application traversal code.
 2. Wire `LoadOptions.Overlay` into `Options.Overlay`. Register
   `--config-overlay` on all five existing configuration-loading command
   modes. Treat the value exactly as an upstream overlay name: no trimming,
   case folding, extension fallback, path expansion, or local inheritance.
   Empty and exact lowercase default mean no active overlay under v0.4.0.
   A requested active overlay without a selected base source fails through
   ConfigKit; do not manufacture an empty base file or root.
 3. Use native `configkit.imports` directives for explicit paths/globs. The
   application enables the feature without requiring a second CLI opt-in;
   absent directives cause no discovery. Retain conflict-based base
   composition and native overlay replacement/null semantics.
 4. Preserve working-directory-relative application path values even when
   authored in fragments or overlays. Configuration-source containment is
   not the HTTP artifact policy and is not applied to prompt/schema paths.
 5. Add focused real-file tests for disjoint backend fragments, an import
   conflict, overlay replacement, explicit CLI precedence, missing selected
   overlay, and no-base overlay failure. Verify `--profile` still selects a
   Promptkit execution profile independently of `--config-overlay`.
   One real command workflow proves wiring; upstream owns exhaustive glob,
   symlink, cycle, and parser-limit tests.
 6. Add a small synthetic import/overlay example under `examples/`; preserve
   a simple single-file quickstart. Update config/CLI contracts and operations
   guidance for the new features, root selection, and relative-value policy.
 Acceptance: supported commands load the same native composition pipeline;
 imports are explicit, overlays remain distinct from execution profiles, and no
 new scanning, remote acquisition, or path policy is introduced.
 ## Stage 5: Add Application Validation, Effective Output, And Source Inspection
 **Status: Complete.** Application-only validation, effective YAML, and ordered
 JSON source inspection use one shared ConfigKit result without an engine. Tests
 cover source composition, CLI provenance, stream failures, and the credential
 reference boundary. Public and internal contracts are updated; full test,
 race, vet, build, and diff checks passed.
 Primary files: a focused `internal/adapter/cli/config.go`, shared config
 definition, CLI dispatch/help/tests, and canonical CLI/config documentation.
 1. Apply the maintainer's selected inspection policy: no redaction for
   `extra_params`, including historical values. API-key values are the only
   relevant secrets, but this schema stores only `api_key_env` reference names.
   Keep those names visible and never resolve them in the ConfigKit load.
   Do not add secret tags to the reference name or parameter container, a
   catch-all secret predicate, sensitive-key guessing, or a selective masking
   interface. Actual credentials remain with Promptkit; raw API-key fields
   remain rejected. Use upstream inspection renderers without adding a second
   value-rendering path or a synthetic credential field.
 2. Add a top-level `config` command family using the existing standard-library
   flag style. The selected interfaces are:
   | Command | Success stdout |
   | --- | --- |
   | `scriptorium config validate [flags]` | Empty; exit status communicates application validation success. |
   | `scriptorium config show [flags]` | `Result.WriteEffective` redacted YAML. |
   | `scriptorium config sources [flags]` | One newline-terminated JSON array of source records. |
   | `scriptorium config explain --path <pointer> [flags]` | Added in Stage 6. |
   These are prospective interface specifications, not commands to execute
   before their stages are implemented.
 3. All configuration subcommands accept `--config`, `--config-overlay`,
   and the eight application override flags in Stage 3's table, regardless
   of which execution command normally uses them. They do not accept request,
   credential, backend-editing, output-format, or output-file flags. Shell
   redirection is sufficient for these inspection outputs. No positional
   arguments are accepted.
 4. Load exactly once through the common loader. Do not construct a Promptkit
   engine, restricted artifact reader, listener, or client. Missing prompt
   directories, unselected/absent credentials, and framework backend validity
   are not additional application-inspection gates. Invalid application
   types/ranges/format still fail. Validation describes application load
   validity, not end-to-end executability.
 5. For sources, map `Result.Sources()` to a small local DTO with JSON keys
   `id`, `label`, `layer` (always present), and `path` (omit when empty).
   Preserve upstream source order; emit `[]\n` for defaults-only input without
   overrides. Include synthetic CLI sources where present. Do not marshal
   opaque ConfigKit implementation objects. The standard JSON encoder escapes
   control characters; no custom terminal rendering is necessary.
 6. Diagnostics/warnings go only to stderr through the shared diagnostic helper.
   Successful operations exit 0; parse/load/output/diagnostic-write failures
   exit 1. No exit 2 meaning is introduced for configuration validation.
   Ordinary writer failures may leave partial output; do not promise atomic
   streams or buffering of an entire configuration.
 7. Test defaults-only show/sources, a composed load with CLI provenance,
   explicit empty clearing, normalized effective values, failed loads producing
   no successful stdout, and writer failure. Set a synthetic API-key environment
   variable: effective output must show its reference name, not its value.
   Repeat with the variable absent to establish that inspection does not require
   credentials. Assert that ordinary synthetic parameter values remain visible
   and runtime ExtraParams stay intact; no real environment or provider is used.
 8. Update CLI/config contracts, README navigation, subprocess integration,
   operations, and internal inventory to describe only these delivered modes.
   Retain the README's license/attribution ending.
 Acceptance: validation, effective output, and source inspection use the same
 resolved configuration as execution, preserve stream separation, and honor the
 selected API-key boundary without masking or changing backend parameter data.
 ## Stage 6: Add Per-Path Explanation And Verify Credential Boundaries
 **Status: Complete.** `config explain` uses required JSON Pointer paths and
 ConfigKit's snapshot renderer, including historical and normalized values.
 Tests cover root, escaped/numeric keys, unknown paths, writer failures, and
 synthetic credential-reference boundaries. Full test, race, vet, build, and
 diff checks passed.
 Primary files: configuration command implementation/tests and CLI/config docs.
 1. Implement `config explain` with the same selectors and override flags as
   Stage 5 plus a required, explicitly supplied `--path`. Parse using
   `configkit.ParsePath`; syntax is JSON Pointer, not dotted notation, a file
   path, or a URL fragment. Explicit `--path ""` selects the root; an omitted
   flag is an error. Preserve escaped and numeric mapping-key semantics.
 2. Use the successful shared result's `WriteExplanation`. Explain known
   effective and historical paths, including removed values. An unknown or
   malformed path exits 1 with no successful explanation output. Quote
   user-supplied paths safely if included in application diagnostics.
   Do not rebuild history, look up environment values, or reload sources.
 3. Keep the upstream human-readable renderer and its redaction semantics rather
   than inventing a JSON explanation schema or freezing the entire rendered
   prose as an application guarantee. Writer failures exit 1 and can leave
   partial output, as with effective output.
 4. Test a value's default/base/overlay/CLI history, recorded normalization,
   explicit equal-value writes, an escaped backend key, root selection, and
   an unknown path. Cover a displaced historical backend parameter value:
   it remains visible, including in a container/root explanation. Use distinct
   synthetic environment names and key values to verify reference names remain
   explainable but resolved API-key bytes are absent from all history/output.
 5. Update CLI/config docs and operations guidance with path syntax,
   historical-value meaning, representation differences, and sensitive
   identifiers/paths. Do not claim that redaction detects arbitrary secrets
   outside classified paths.
 Acceptance: explain uses the existing snapshot and upstream semantics; its
 history matches the selected inputs and normalization, parameters remain
 visible, and explanation neither resolves nor discloses API-key values.
 ## Stage 7: Verify Integration, Finish Documentation, And Record Release Handoff
 **Status: Complete.** The feature roadmap, command paths, dependency boundary,
 documentation, and attribution were audited. Maintained single-file and
 composed examples passed configuration inspection and no-provider rendering;
 the optional-credential/integer-parameter backend path passed with a local
 provider. The full test, race, vet, build, formatting, link, and diff checks
 passed. Release preparation is recorded below; no tag or publication occurred.
 1. Review the feature roadmap against actual code. Confirm all five original
   command modes and all four new configuration subcommands use one definition
   and load pipeline. Remove any transitional loader, duplicated defaults,
   unused compatibility helpers, or post-snapshot configuration mutation.
   Do not add architecture machinery merely to assert a particular file layout.
 2. Exercise maintained single-file and import/overlay examples through the
   implemented configuration commands and a no-provider render workflow.
   Use focused backend integration evidence that dynamic integer parameters
   reach Promptkit correctly and missing optional credentials retain their
   established meaning. Use a local HTTP server only where provider serialization
   must be checked; never a real service or credential.
 3. Retain existing HTTP concurrency, containment, error mapping, retry,
   timeout, and report tests. Add a representative configuration-to-server
   wiring test only if existing coverage misses changed settings propagation;
   do not reproduce all upstream scheduling or HTTP cases.
 4. Run the development baseline on final code: `go test ./...`,
   `go test -race ./...`, `go vet ./...`, and
   `go build ./cmd/scriptorium`. Check formatting, affected examples/links,
   and `git diff --check`. Do not stage the built binary or scratch files.
   Compare any new standard license text byte-for-byte; preserve upstream
   whitespace rather than editing license wording to satisfy a style check.
 5. Ensure current configuration, CLI, subprocess, operations, internal docs,
   contributor routing, and architecture ownership agree. Testing policy
   should identify ConfigKit as the owner of exhaustive upstream loading tests,
   while Scriptorium owns application adoption tests. Change policy dates when
   revising policies, not base versions unless adopting new templates.
   Keep accepted ADR text and published release notes immutable.
 6. Record the release handoff below and mark only delivered stages complete.
   Update the feature roadmap's status, including the resolved inspection
   decision. Preserve deferred work. The next breaking release follows the
   release policy; version selection, candidate publication validation, release
   notes at that version, tag creation, and publishing are not this sprint.
 7. Commit the final coherent handoff and report validation evidence, remaining
   limitations, and any outstanding work without claiming source/binary
   publication or complete legal compliance.
 Acceptance: the ConfigKit-native target is delivered with proportionate
 regression evidence and accurate documentation, and the workspace contains no
 temporary dependency substitutions or uncommitted implementation artifacts.
 ### Release Handoff To Retain
 The upcoming release needs migration guidance for empty files versus `{}`,
 explicit empty values, nullable versus scalar fields, strict YAML/scalars,
 reserved keys and upstream size limits, and the invalid explicit-empty config
 path. Include imports/overlays, application path interpretation, CLI presence,
 inspection command scope, and the selected API-key-only secret policy. Explicit
 empty server address reaches standard HTTP server behavior instead of restoring
 Scriptorium's default; operators should supply their intended listen address.
 Keep request retry overrides and Promptkit credential semantics distinct from
 application settings. Explain that configuration validation is not a provider
 probe or complete Promptkit definition validator, and that inspection output
 is not guaranteed reloadable. Include dependency/attribution changes and the
 existing LICENSE | ATTRIBUTION footer. Preserve the still-relevant Promptkit
 v0.11 release handoff identified above when preparing a combined next release.
 ### Implementation And Release Preparation Record
 The ConfigKit v0.4.0 adoption is implemented in committed source. The next
 breaking release still needs version selection, version-matched release notes,
 candidate validation, tagging, and publication under the release policy; none
 has occurred as part of this work. Keep the earlier Promptkit v0.11 handoff
 linked above when preparing a combined release.
 The release note should summarize the deliberate configuration migration:
 empty files now fail and `{}` means an empty mapping; explicitly empty strings
 and zero values override lower values; `null` follows declared nullable types;
 strict YAML rejects additional documents, anchors/aliases, unsupported scalar
 forms, and unknown fields; `configkit` is reserved and ConfigKit's source and
 resource limits apply. Explicit `--config ''` is invalid. Imports are opt-in
 per file directive, while `--config-overlay` selects one named overlay under
 the selected file's canonical directory; application path *values* remain
 process-working-directory-relative. Only explicitly supplied application CLI
 flags override configuration. An explicit empty server address is passed to
 the standard HTTP server and does not restore Scriptorium's default.
 Document the four application-inspection modes and the selected policy:
 `extra_params`, including history, and `api_key_env` reference names remain
 visible, but actual API-key bytes are never resolved by ConfigKit. Inspection
 output can be sensitive and is not guaranteed reloadable. Application
 validation neither probes a provider nor completely validates Promptkit
 definitions. Keep request retry overrides and Promptkit's credential rules
 separate from application settings. Include the new dependency and attribution
 notices, and retain the existing LICENSE | ATTRIBUTION footer. Deferred
 secrets bootstrap, schema versioning, reload, and remote acquisition remain
 deferred; do not imply source or binary publication has happened.
 ## Open Questions
-None remain for this scope. On 2026-09-26 the maintainer selected no redaction
+None. The maintainer approved the public discovery URLs, the standard
-for `extra_params` and specified that the API key is the only secret requiring
+CC-BY-SA arrangement for copied policy material, the selected upstream revision,
-ConfigKit redaction. Stages 5–6 implement that decision through visible parameter
+and the justified local variations. The existing application grant, dependency
-values/reference names and the existing separation of actual credentials from
+grants, and release approach remain unchanged; do not reopen them merely to
-application configuration. Do not reopen it or substitute blanket masking.
+perform this adoption.
 This does not claim automatic detection of credentials embedded in arbitrary
 strings or provider parameters. The application schema still rejects raw API-key
 fields, and Promptkit remains responsible for resolving named credential sources.
--- a/docs/roadmap/policy.md
+++ b/docs/roadmap/policy.md
@@ -1,63 +1,223 @@
-# OSS Policy Adoption
+# Standard Repository Policy Alignment
-## Status
+## Status And Intent
-Completed on 2026-09-26. The upstream template work proposed here is now
+Agreed and delivered on 2026-09-28. This roadmap replaces the
-available and adopted locally. This document records the adoption; the
+earlier licensing-only proposal with alignment of the complete applicable
-[OSS policy](../policy/oss.md) is the canonical owner of the ongoing rules.
+policy set and its supporting documentation. It defines the targeted end state
 and required changes; the [implementation plan](implementation.md) owns ordered
 stages and their verification.
-The adopted baseline is the standard policy repository at commit
+The next release summary should mention the policy and licensing alignment,
-`eea8bcd21a964b395e31971077d7fddb445f2c28`:
+the already-selected GPL-3.0-or-later application grant, and the separate
 CC-BY-SA-4.0 treatment of adapted policy material. Version selection and
 publication remain release preparation, not part of this delivery.
- OSS policy base version 1.1;
+The goal is identical policy language across adopting projects except where a
- documentation policy base version 1.4; and
+substantive, locally significant requirement or decision warrants customization.
- release policy base version 1.2.
+Adopt upstream wording verbatim for non-substantive differences. Existing local
 phrasing is not, by itself, a reason to retain a variation.
-Each affected policy records its base version and local update date. Template
+## Review Revision And Current Baseline
 adoption instructions were removed. Unchanged agent, architecture, and testing
 policies retain their existing versions.
-## Adoption Outcome
+The fixed upstream review revision is
 `d84a38ebab26f048cafbe59a2246700c35d29843`.
 Use the [adoption and update guide at that revision](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md)
 for this adoption. The review compared current local documents directly with
 that revision; reconstruction or assessment of historical adoption baselines
 is not required.
- [Documentation ownership](../policy/documentation.md) distinguishes the
+The reviewed Scriptorium revision is
-  project license, component entries, standard texts, and OSS policy.
+`d6aecf5c50269b7d130dbf19f416a67454cd9778`. It has six adopted policies,
- The [contributor guide](../development.md) routes dependency, copied-asset,
+without per-document Upstream Source metadata, and no `docs/policy/meta.md`.
-  attribution, and release-document work to the OSS policy.
+The policy targets below supersede the earlier roadmap's narrower version
- [Component entries](../oss/attribution.md) cover the six selected direct and
+targets.
  transitive Go modules. Source and project-specific notice links identify the
  imported commits. LGPL entries link directly to both LGPL v3 and GPL v3.
 - Project-specific notices are linked upstream under the adopted house
  interpretation. YAML's former local LICENSE and NOTICE copies were removed;
  their history remains in Git. Missing upstream copyright statements are
  identified in the affected entries rather than fabricated.
 - The five applicable standard texts in `docs/oss/licenses/` match the upstream
  reference collection byte-for-byte: GPL v3, LGPL v3, Apache 2.0, BSD 3-Clause,
  and MIT. The reference collection documents their publisher/SPDX provenance.
  Adoption removed a stray LGPL prefix, restored the complete Apache text,
  separated the standard BSD text from the Go-specific notice, and added MIT.
 - The [README](../../README.md) ends with friendly project-license and
  attribution links. The [release policy](../policy/release.md) delegates footer
  conventions to the OSS policy; the [release procedure](../release.md) retains
  Scriptorium's immutable-tag URLs and existing hosted-body reuse.
-## Preserved Scope
+| Policy and proposed Upstream Source | Current base | Target base | Target treatment |
 | --- | --- | --- | --- |
 | [agents.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md) | 1.1 | 1.3 | Adopt shared rules verbatim, including commit discipline. |
 | [architecture.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md) | 1.1 | 1.3 | Adopt common principles and customize for Scriptorium's established boundaries. |
 | [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md) | 1.4 | 1.11 | Adopt shared language and tailor the canonical topic map. |
 | [testing.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md) | 1.1 | 1.3 | Adopt shared guidance with focused local test ownership. |
 | [release.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md) | 1.2 | 1.4 | Adopt common rules and retain justified release choices. |
 | [oss.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md) | 1.1 | 1.8 | Adopt licensing, attribution, and reference-example conventions. |
 | [meta.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md) | Not adopted | 1.0 | Add provenance, local authority, and upstream discovery. |
-This adoption changes documentation and attribution, not Scriptorium's license,
+Every existing policy needs language and provenance updates. No adopted policy
-dependencies, application architecture, or release machinery. Published notes,
+is entirely update-free, but established application decisions, dependency
-tags, and assets remain unchanged. Existing source-release completion and
+licenses, and release mechanics need no substantive change.
 asynchronous binary-delivery behavior remain intact.
-There is no new publication-time network check, approval gate, scanner, source
+Current supporting-document gaps include the README's obsolete BSD project
-bundle, downloadable license asset, or modified-dependency rebuild exercise.
+license statement, the release procedure's two-link footer, an attribution
-Concrete exceptions continue to receive the treatment specified by the adopted
+document that does not follow the new exact House Format, and orientation
-OSS policy; the house format is not a universal legal-sufficiency guarantee.
+guidance that requires architecture reading even for unrelated work.
 The architecture policy's command inventory also omits the implemented
 `config` command family.
-## Validation
+## Target Policy Language And Local Customizations
-The standard texts were compared against the upstream reference collection.
+Remove every `Base Policy Template` section and its adoption instructions.
-The BSD reference intentionally retains its publisher's trailing space in the
+Replace instructional application-specific placeholders with actual decisions;
-copyright placeholder; it is not reformatted to satisfy a whitespace check.
+do not leave template examples describing nonexistent components.
-Dependency commit references were resolved from Go module origin metadata or
+
-the selected upstream tag, and affected local links and upstream attribution
+Use upstream common language verbatim. Keep necessary local requirements
-destinations were checked. No runtime code, commands, or executable examples
+clearly identifiable rather than paraphrasing entire shared sections.
-changed.
+The following customizations are justified:
 - **Architecture:** preserve PromptKit and ConfigKit ownership, full support
  for valid PromptKit definitions, public dependency boundaries, HTTP artifact
  containment, and simple predefined-prompt execution. Preserve caller-visible
  request independence alongside shared engine and backend capacity state.
  These are deliberate product and safety decisions, not generic template
  choices. Adopt upstream architectural principles proportionately; they do
  not require a wrapper or interface for every library. Correct the command
  inventory and keep concrete package mechanics in internal documentation.
 - **Documentation ownership:** tailor the topic map to the executable CLI and
  HTTP application. Scriptorium does not offer a reusable public Go API;
  consumer guidance covers executable use and migration to PromptKit.
  PromptKit remains the owner of framework formats. Use upstream wording for
  generic ownership, example, and ADR guidance instead of retaining redundant
  local paraphrases. Preserve accepted ADR decisions and their history.
 - **Testing:** retain a short project-specific ownership section distinguishing
  Scriptorium's integration and adapter tests from upstream framework/parser
  tests. This prevents duplication of PromptKit and ConfigKit test matrices.
  HTTP containment and shared-capacity behavior justify focused adapter
  coverage. Upstream observations about domain coverage are not quotas or a
  hierarchy that displaces risk-based testing.
 - **Release:** preserve branch-before-tag publication, annotated tags,
  Linux amd64/arm64 binaries and checksums, and asynchronous artifact delivery.
  Retain race testing because the server shares concurrent engine state and
  source guards because local replacements, workspaces, or vendoring can hide
  unpublished dependency substitutions. Keep gate rationale in policy and
  concrete commands, targets, and publication choices in the release procedure.
  Upstream's optional atomic-push approach does not require a new feature.
 - **OSS:** use Scriptorium's actual GPL-3.0-or-later grant in the project
  example. Preserve dependency grants and the settled House Format
  interpretation for upstream notice links. The code grant does not extend
  to separately licensed copied policy material.
 No agent-policy exception is needed: upstream already preserves the local
 commit authorization and safety boundaries. Stylistic preferences, alternate
 wording, and generic elaboration do not justify additional exceptions.
 ## Provenance And Public Discovery
 When adoption lands, each of the seven policies records its target
 `Base Policy Version`, actual local adoption date in `Last Updated`, and
 `Upstream Source` pointing to the exact corresponding file linked in the
 table above. Do not substitute a repository homepage, moving branch, another
 policy's URL, or a historical source revision for that per-document link.
 Retain accurate provenance in later local edits.
 The new local `docs/policy/meta.md` follows upstream language after removing
 its template section. It establishes that adopted local policies govern the
 repository and that upstream changes require deliberate adoption. Its public
 discovery links remain current:
 - [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
 - [Current adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
 Adopted-source and example links remain commit-pinned. Preserve the valid
 commit-pinned example links supplied in the selected OSS policy; their asset
 revision need not be rewritten merely to match the policy review revision.
 Public discovery and attribution in this agreed adoption supersede the earlier
 instruction not to reference the policy repository.
 ## Orientation And Selective Reading
 Adapt [the upstream agent orientation](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/agents/AGENTS.md)
 into [root AGENTS.md](../../AGENTS.md), preserving applicable existing
 code-discovery instructions. It points to the local contributor guide and
 requires the agent policy before recommendations, planning, or implementation;
 it does not require reading the entire suite by default.
 The [contributor guide](../development.md) gains the upstream Policy Reading
 Guide table and associated selection rules, including the new meta policy.
 Retain Scriptorium's task-specific contract guide alongside it. Architecture
 reading becomes task-triggered rather than unconditional. Relevant policies
 are read before governed decisions, multiple policies may apply, material
 already available in context may be reused, and expanded scope triggers
 expanded reading. Policy-reading triggers live here, not in the documentation
 topic map.
 ## Licensing And Attribution
 Follow the [canonical copied-policy attribution entry](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/examples/licensing/policy-attribution.md).
 Insert it directly beneath the prescribed attribution title and replace all
 three placeholder URLs with the full review commit. Identify the actual
 copied/adapted scope, including agent-orientation material and copied reading
 guidance where used, rather than describing only policy files if additional
 material is incorporated. Preserve creator, copyright, license, disclaimer,
 and modification information through the supplied notices and links.
 Required supporting changes:
 - Add the complete, unmodified `docs/oss/licenses/CC-BY-SA-4.0.txt` from the
  selected revision.
 - Extend [COPYRIGHT](../../COPYRIGHT) to identify the adapted policy material
  as CC-BY-SA-4.0 and point to attribution for exact scope. Preserve
  Scriptorium's GPL-3.0-or-later code grant and existing [LICENSE](../../LICENSE).
  Unrelated application documentation is not automatically relicensed.
 - Reformat [attribution](../oss/attribution.md) to the v1.8 House Format:
  `# Open Source Attribution Notices`, followed directly by component entries;
  factual optional identification; supplied copyrights; SPDX expressions;
  license/notice links with actual filename labels and terminal periods;
  and `[Source](COMMIT_URL).`.
 - Remove its introductory policy prose, missing-copyright filler, and
  agent-authored license-scope explanations. Omit an unavailable copyright
  field instead of explaining that none was invented. Preserve actual
  required upstream notices, applicable license expressions, and imported
  dependency revisions.
 - Correct [README](../../README.md) to link its GPL v3 or later statement to
  `COPYRIGHT`, followed by the attribution link.
 - Update [the release procedure](../release.md) to use the prospective
  `COPYRIGHT | LICENSE | ATTRIBUTION` footer, with absolute immutable-release
  URLs for all three destinations. The existing hosted workflow continues
  copying the checked-in release note unchanged.
 The documented CC-BY-SA arrangement is agreed for this adoption. Original
 licensing-example formatting has upstream's CC0 permission; using it alone
 does not require a separate attribution entry. Reproduced license texts and
 third-party notices retain their own terms.
 ## Local Materials And Upstream References
 Keep applicable adopted policies, Scriptorium's adapted root orientation and
 developer guide, actual project notices, attribution entries, and required
 license texts locally.
 Keep the upstream adoption guide, README, root AGENTS.md, developer guide, and
 example collection upstream. Link to them as appropriate rather than copying
 them into a parallel local handbook. The upstream `agents/AGENTS.md` is the
 downstream orientation template, distinct from upstream's own root AGENTS.md.
 Copy only needed standard license texts, not the entire reference collection.
 ## Scope And Completion Criteria
 This work updates policy and supporting documentation. It does not change
 application code, dependency versions or grants, release scripts, publication
 mechanics, or accepted ADR decisions. No new scanner, recurring synchronization
 check, license approval, publication-time network probe, or release gate is
 introduced. Published releases, tags, notes, and assets remain unchanged.
 Completion means:
 - All seven policy files use the selected versions, accurate source links,
  adoption dates, and upstream common wording, with template-only content
  removed and local variations limited to the justified decisions above.
 - Orientation and selective reading agree, and local links resolve without
  depending on a sibling checkout.
 - Policy attribution and document-license scope match the material actually
  incorporated; required standard texts are complete and unmodified.
 - README, attribution, release navigation, and still-operative roadmap
  handoffs agree with the new conventions. Historical implementation evidence
  remains available through the Git references in the implementation plan,
  without making old footer directions current policy. The earlier
  author-selected license change remains in the next release's preparation
  context; publication remains separate work.
 - Review checks the resulting rules, source/example URLs, notice facts, local
  links, license-text fidelity, and final diff. Runtime tests are unnecessary
  for documentation-only changes. A Git adoption record is sufficient; no
  additional provenance database or recurring audit is required.
 There are no unresolved policy choices for this scope.
--- a/docs/roadmap/promptkit-v0.9.0-adoption.md
+++ b/docs/roadmap/promptkit-v0.9.0-adoption.md
@@ -3,8 +3,9 @@
 ## Status
 Complete. This document records the delivered feature scope and targeted end
-state. The completed delivery plan is maintained in
+state. The completed delivery plan is preserved at
-[implementation.md](implementation.md); current behavior remains defined by
+`git show e4405966c87c8a7843b340146e90cc1e515bef42:docs/roadmap/implementation.md`;
 current behavior remains defined by
 the canonical application contracts linked below.
 The durable product and integration boundary for this work is established by
--- a/docs/roadmap/upgrade-kit.md
+++ b/docs/roadmap/upgrade-kit.md
@@ -8,7 +8,8 @@ and publication remain separate release preparation. The baseline descriptions
 below record the state when this roadmap was written, not current behavior.
 Upgrade directly from Promptkit v0.9.0 to v0.11.0, including the intervening
 v0.10.0 catalog transition. This document defines the desired end state and
-the changes from the current baseline. The [implementation plan](implementation.md)
+the changes from the current baseline. The historical plan at
 `git show 43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c:docs/roadmap/implementation.md`
 owns sequencing, concrete interface choices, verification steps, and unresolved
 implementation decisions.
@@ -268,6 +269,6 @@ boundaries.
  the version-matched note remain release preparation.
 Concrete interface decisions and the selected distribution approach are recorded
-in the completed [implementation plan](implementation.md). They do not expand
+in that completed historical plan. They do not expand
 the product into conversations, follow-up messages, application-owned semantic
 retry loops, prepared-handle coordination, or multi-step workflows.
--- a/go.mod
+++ b/go.mod
@@ -3,13 +3,13 @@ module gitea.maximumdirect.net/eric/scriptorium
 go 1.25.5
 require (
-	gitea.maximumdirect.net/eric/ConfigKit v0.4.0
+	gitea.maximumdirect.net/eric/ConfigKit v0.4.2
-	gitea.maximumdirect.net/eric/promptkit v0.11.0
+	gitea.maximumdirect.net/eric/promptkit v0.11.2
 )
 require (
-	gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1 // indirect
+	gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 // indirect
-	gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0 // indirect
+	gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0 // indirect
 	github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect
 	go.yaml.in/yaml/v4 v4.0.0-rc.6 // indirect
 	golang.org/x/text v0.14.0 // indirect
--- a/go.sum
+++ b/go.sum
@@ -1,11 +1,11 @@
-gitea.maximumdirect.net/eric/ConfigKit v0.4.0 h1:fo+vKff3zTGeWqJIA38NtT84b6OUP//9ZmBH3lFuKgk=
+gitea.maximumdirect.net/eric/ConfigKit v0.4.2 h1:ZMxmv8pOnLtAx2hFTf8Z+pHKUbR89xErkBhwjr4yK24=
-gitea.maximumdirect.net/eric/ConfigKit v0.4.0/go.mod h1:tYWpsrbLyu05r8+1MapWp5fN6ZrX9I8hU2xEPedYmYk=
+gitea.maximumdirect.net/eric/ConfigKit v0.4.2/go.mod h1:tYWpsrbLyu05r8+1MapWp5fN6ZrX9I8hU2xEPedYmYk=
-gitea.maximumdirect.net/eric/promptkit v0.11.0 h1:x7JguOUiInPVXK0GEitjyoRFqqvcuSTjYUvqJ+whtik=
+gitea.maximumdirect.net/eric/promptkit v0.11.2 h1:2RqI+KtflvSh7vLQaTAQCmMaFQscEA7EPwPazyvXRoY=
-gitea.maximumdirect.net/eric/promptkit v0.11.0/go.mod h1:0zEBVlJJC+ldDdXazAgybYBXNSe74vwFx5dyOuSos/w=
+gitea.maximumdirect.net/eric/promptkit v0.11.2/go.mod h1:onm/FBPUKQ8/NSPwTEk26Ut+dVX2iXcq8vEseB+g/0E=
-gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1 h1:S2/Q/JDE+m8Ca3pDhAjVbfYrdlEhs9blj0STgNopHo0=
+gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 h1:wdab+R+lgMZxzYwhbAuCrW7zdSQ1cW9ovBR6UzLmZR4=
-gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1/go.mod h1:a3VBbh9oaGXD6ruxhtwHj+AWW6DY/SSyby1QtMmYSUo=
+gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0/go.mod h1:a3VBbh9oaGXD6ruxhtwHj+AWW6DY/SSyby1QtMmYSUo=
-gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0 h1:Y0EXc3eh12eKW2NrOviVqdk3oBo6UUjopt1YAa1B3Oc=
+gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0 h1:baCCIB6Ee5t0S4Zc++NTBIPcJEv5UPS6DlSrpZfykwg=
-gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
+gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
 github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI=
 github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8=
 github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ=
Author	SHA1	Message	Date
Eric Rakestraw	9849c6bda2	Prepare Scriptorium v0.15.0 release notes All checks were successful ci/woodpecker/tag/release Pipeline was successful Details	2026-09-28 03:01:09 +00:00
Eric Rakestraw	777b727602	Update ConfigKit and PromptKit patch versions	2026-09-28 02:41:03 +00:00
Eric Rakestraw	81e1ef59e6	Clarify interface guidance and completed plan status	2026-09-28 02:25:45 +00:00
Eric Rakestraw	df762c3735	Complete policy alignment documentation handoff	2026-09-28 01:47:05 +00:00
Eric Rakestraw	417522f08c	Align release policy with existing publication workflow	2026-09-28 01:44:38 +00:00
Eric Rakestraw	b3bb36fc86	Align architecture and testing policies with upstream	2026-09-28 01:43:29 +00:00
Eric Rakestraw	ba0d99f107	Adopt policy provenance and documentation guidance	2026-09-28 01:41:33 +00:00
Eric Rakestraw	538bc27472	Adopt open source policy and licensing notices	2026-09-28 01:39:10 +00:00
Eric Rakestraw	1bad076d48	Plan the policy alignment implementation	2026-09-28 01:14:38 +00:00
Eric Rakestraw	8452b54809	Revise the policy alignment roadmap	2026-09-28 01:11:57 +00:00
Eric Rakestraw	d6aecf5c50	Update library patches and licensing attribution	2026-09-26 22:01:03 +00:00
Eric Rakestraw	83856b4de8	Document the licensing policy alignment roadmap	2026-09-26 20:48:35 +00:00
Eric Rakestraw	39d3508705	Fix license name typos in COPYRIGHT	2026-09-26 20:38:50 +00:00
Eric Rakestraw	856d0852e7	Align the COPYRIGHT and LICENSE documents with the house standard	2026-09-26 14:59:52 -05:00