feat(agents-api): Implement doc* models

[creatorrr]

• refactor(agents-api): Minor refactors
• feat(typespec): Add create-doc endpoint
• feat(agents-api): Add migrations for unifying the owner-docs tables
• feat(agents-api): Implement doc* models

---

🚀	This description was created by Ellipsis for commit 22211fe

Summary:

Implemented new document models and endpoints for the agents API, including create, delete, embed, and search functionalities, along with necessary migrations and SDK updates.

Key points:

• New Models: Added CreateDocRequest, Snippet, and updated DocReference in agents-api/agents_api/autogen/Docs.py.
• Endpoints: Implemented create_doc, delete_doc, embed_snippets, get_doc, list_docs, and search_docs_by_embedding in agents-api/agents_api/models/docs.
• Migrations: Added migration script migrate_1722710530_unify_owner_doc_relations.py to unify owner-doc tables.
• SDK Updates: Updated Python and TypeScript SDKs to include new document models and endpoints.
• Refactors: Minor refactors in agents-api/agents_api/models/__init__.py and related files.

---

Generated with ❤️ by ellipsis.dev

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 22211fe in 1 minute and 43 seconds

More details

• Looked at 3100 lines of code in 54 files
• Skipped 3 files when reviewing.
• Skipped posting 6 drafted comments based on config settings.

1. sdks/python/julep/api/types/docs_create_doc_request.py:5

• Draft comment:
  The DocsCreateDocRequestContent type is imported but not used directly in this file. It's used indirectly in the content field definition. This might be confusing as it's not clear from this file alone what DocsCreateDocRequestContent entails without looking at its definition. Consider adding a comment here explaining that DocsCreateDocRequestContent can be either a string or a list of strings.
• Reason this comment was not posted:
  Confidence changes required: 33%
  The import of DocsCreateDocRequestContent is used in the definition of the content field of the DocsCreateDocRequest model. However, the actual type isn't visible in this file, which might confuse someone who isn't looking at the DocsCreateDocRequestContent definition directly. A comment could help clarify this indirect usage.

2. sdks/python/julep/api/types/docs_doc_reference.py:25

• Draft comment:
  The snippets field in DocsDocReference is defined as a list of DocsSnippet, which is required to have at least one item due to the @minItems(1) annotation. This is a good practice as it ensures that when a DocsDocReference is used, it always has at least one snippet, which is likely a requirement for the functionality relying on this model.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The model DocsDocReference includes a snippets field that must have at least one item. This is a good design decision because it enforces that there are always snippets to work with when handling a document reference, which is likely important for the operations that use this model.

3. sdks/python/julep/api/types/docs_hybrid_doc_search_request.py:17

• Draft comment:
  The vector field in DocsHybridDocSearchRequest is correctly defined as a list of floats, which is appropriate for representing a vector in search queries. This aligns well with the typical usage of vectors in search algorithms where a vector represents a point in a multidimensional space.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The vector field in the DocsHybridDocSearchRequest model is defined as a list of floats, which is standard for representing vectors in programming and data science, particularly in contexts involving search and machine learning algorithms.

4. sdks/python/julep/api/types/docs_snippet.py:6

• Draft comment:
  The DocsSnippet model is well-defined with index and content fields. This model is likely used to represent segments of a document, where index could denote the order or position of the snippet in the document, and content is the actual text of the snippet. This is a typical pattern for handling segmented text data.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The DocsSnippet model includes index and content fields, which are essential for representing parts of a document in a structured way. This model is straightforward and aligns with common practices in handling text data that is broken into segments or snippets.

5. sdks/python/julep/api/types/docs_text_only_doc_search_request.py:12

• Draft comment:
  The text field in DocsTextOnlyDocSearchRequest is appropriately defined as a single string, which is suitable for scenarios where a text-based search is performed without the need for vector data. This simplifies the usage of the model in purely text-based search contexts.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The DocsTextOnlyDocSearchRequest model is specifically for text-only searches, and the text field is correctly a single string. This is ideal for search functionalities that operate solely on textual data, ensuring the model is not overloaded with unnecessary fields.

6. sdks/python/julep/api/types/docs_vector_doc_search_request.py:12

• Draft comment:
  The vector field in DocsVectorDocSearchRequest is correctly defined as a list of floats. This is essential for vector-based search functionalities where each float in the list represents a dimension in the vector space used for search operations.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The DocsVectorDocSearchRequest model is designed for vector-based searches, and the vector field is appropriately a list of floats. This is standard practice for representing vectors in search algorithms, where each float corresponds to a dimension in a multidimensional space.

Workflow ID: wflow_ZdigQcudENyC8Sq9

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.